CVS(1) General Commands Manual CVS(1)

CVS(1) General Commands Manual CVS(1) #

CVS(1) General Commands Manual CVS(1)

NNAAMMEE #

 cvs - Concurrent Versions System

SSYYNNOOPPSSIISS #

 ccvvss [ _c_v_s___o_p_t_i_o_n_s ]
        _c_v_s___c_o_m_m_a_n_d [ _c_o_m_m_a_n_d___o_p_t_i_o_n_s ] [ _c_o_m_m_a_n_d___a_r_g_s ]

NNOOTTEE #

 This manpage is a summary of some of the features of ccvvss but for more in-
 depth documentation, consult the Cederqvist manual (as described in the
 SEE ALSO section of this manpage).

DDEESSCCRRIIPPTTIIOONN #

 CVS is a version control system, which allows you to keep old versions of
 files (usually source code), keep a log of who, when, and why changes
 occurred, etc., like RCS or SCCS.  Unlike the simpler systems, CVS does
 not just operate on one file at a time or one directory at a time, but
 operates on hierarchical collections of directories consisting of version
 controlled files.  CVS helps to manage releases and to control the
 concurrent editing of source files among multiple authors.  CVS allows
 triggers to enable/log/control various operations and works well over a
 wide area network.

 ccvvss keeps a single copy of the master sources.  This copy is called the
 source ``repository''; it contains all the information to permit
 extracting previous software releases at any time based on either a
 symbolic revision tag, or a date in the past.

EESSSSEENNTTIIAALL CCOOMMMMAANNDDSS #

 ccvvss provides a rich variety of commands (_c_v_s___c_o_m_m_a_n_d in the Synopsis),
 each of which often has a wealth of options, to satisfy the many needs of
 source management in distributed environments.  However, you don't have
 to master every detail to do useful work with ccvvss; in fact, five commands
 are sufficient to use (and contribute to) the source repository.

 ccvvss cchheecckkoouutt _m_o_d_u_l_e_s...
        A necessary preliminary for most ccvvss work: creates your private
        copy of the source for _m_o_d_u_l_e_s (named collections of source; you
        can also use a path relative to the source repository here).  You
        can work with this copy without interfering with others' work.  At
        least one subdirectory level is always created.

 ccvvss uuppddaattee
        Execute this command from _w_i_t_h_i_n your private source directory
        when you wish to update your copies of source files from changes
        that other developers have made to the source in the repository.

 ccvvss aadddd _f_i_l_e...
        Use this command to enroll new files in ccvvss records of your
        working directory.  The files will be added to the repository the
        next time you run `ccvvss ccoommmmiitt'.  Note: You should use the `ccvvss
        iimmppoorrtt' command to bootstrap new sources into the source
        repository.  `ccvvss aadddd' is only used for new files to an already
        checked-out module.

 ccvvss rreemmoovvee _f_i_l_e...
        Use this command (after erasing any files listed) to declare that
        you wish to eliminate files from the repository.  The removal does
        not affect others until you run `ccvvss ccoommmmiitt'.

 ccvvss ccoommmmiitt _f_i_l_e...
        Use this command when you wish to ``publish'' your changes to
        other developers, by incorporating them in the source repository.

OOPPTTIIOONNSS #

 The ccvvss command line can include _c_v_s___o_p_t_i_o_n_s, which apply to the overall
 ccvvss program; a _c_v_s___c_o_m_m_a_n_d, which specifies a particular action on the
 source repository; and _c_o_m_m_a_n_d___o_p_t_i_o_n_s and _c_o_m_m_a_n_d___a_r_g_u_m_e_n_t_s to fully
 specify what the _c_v_s___c_o_m_m_a_n_d will do.

 _W_a_r_n_i_n_g_: you must be careful of precisely where you place options
 relative to the _c_v_s___c_o_m_m_a_n_d.  The same option can mean different things
 depending on whether it is in the _c_v_s___o_p_t_i_o_n_s position (to the left of a
 ccvvss command) or in the _c_o_m_m_a_n_d___o_p_t_i_o_n_s position (to the right of a ccvvss
 command).

 There are only two situations where you may omit _c_v_s___c_o_m_m_a_n_d: `ccvvss --HH' or
 `ccvvss ----hheellpp' elicits a list of available commands, and `ccvvss --vv' or `ccvvss
 ----vveerrssiioonn' displays version information on ccvvss itself.

CCVVSS OOPPTTIIOONNSS #

 As of release 1.6, ccvvss supports GNU style long options as well as short
 options.  Only a few long options are currently supported, these are
 listed in brackets after the short options whose functions they
 duplicate.

 Use these options to control the overall ccvvss program:

 --HH [[ ----hheellpp ]]
        Display usage information about the specified _c_v_s___c_o_m_m_a_n_d (but do
        not actually execute the command).  If you don't specify a command
        name, `ccvvss --HH' displays a summary of all the commands available.

 --RR     Allows ccvvss to run properly without write access to its log file.
        See also the CVSREADONLYFS environment variable.

 --QQ     Causes the command to be _r_e_a_l_l_y quiet; the command will generate
        output only for serious problems.

 --qq     Causes the command to be somewhat quiet; informational messages,
        such as reports of recursion through subdirectories, are
        suppressed.

 --bb _b_i_n_d_i_r
        Use _b_i_n_d_i_r as the directory where RCS programs are located (CVS
        1.9 and older).  Overrides the setting of the RCSBIN environment
        variable.  This value should be specified as an absolute pathname.

 --dd _C_V_S___r_o_o_t___d_i_r_e_c_t_o_r_y
        Use _C_V_S___r_o_o_t___d_i_r_e_c_t_o_r_y as the root directory pathname of the
        master source repository.  Overrides the setting of the CVSROOT
        environment variable.  This value should be specified as an
        absolute pathname.

 --ee _e_d_i_t_o_r
        Use _e_d_i_t_o_r to enter revision log information.  Overrides the
        setting of the CVSEDITOR, VISUAL, and EDITOR environment
        variables.

 --ff     Do not read the ccvvss startup file (_~_/_._c_v_s_r_c).

 --ll     Do not log the _c_v_s___c_o_m_m_a_n_d in the command history (but execute it
        anyway).  See the description of the hhiissttoorryy command for
        information on command history.

 --nn     Do not change any files.  Attempt to execute the _c_v_s___c_o_m_m_a_n_d, but
        only to issue reports; do not remove, update, or merge any
        existing files, or create any new files.

 --tt     Trace program execution; display messages showing the steps of ccvvss
        activity.  Particularly useful with --nn to explore the potential
        impact of an unfamiliar command.

 --rr     Makes new working files read-only.  Same effect as if the CVSREAD
        environment variable is set.

 --vv [[ ----vveerrssiioonn ]]
        Displays version and copyright information for ccvvss.

 --ww     Makes new working files read-write (default).  Overrides the
        setting of the CVSREAD environment variable.

 --xx     Encrypt all communication between the client and the server.  As
        of this writing, this is only implemented when using a Kerberos
        connection.

 --zz _c_o_m_p_r_e_s_s_i_o_n_-_l_e_v_e_l
        When transferring files across the network use ggzziipp compression
        level _c_o_m_p_r_e_s_s_i_o_n_-_l_e_v_e_l to compress and de-compress data as it is
        transferred.

UUSSAAGGEE #

 Except when requesting general help with `ccvvss --HH', you must specify a
 _c_v_s___c_o_m_m_a_n_d to ccvvss to select a specific release control function to
 perform.  Each ccvvss command accepts its own collection of options and
 arguments.  However, many options are available across several commands.
 You can display a usage summary for each command by specifying the --HH
 option with the command.

CCVVSS SSTTAARRTTUUPP FFIILLEE #

 Normally, when CVS starts up, it reads the _._c_v_s_r_c file from the home
 directory of the user reading it.  This startup procedure can be turned
 off with the --ff flag.

 The _._c_v_s_r_c file lists CVS commands with a list of arguments, one command
 per line.  For example, the following line in _._c_v_s_r_c:

 diff -c

 will mean that the `ccvvss ddiiffff' command will always be passed the -c option
 in addition to any other options that are specified in the command line
 (in this case it will have the effect of producing context sensitive
 diffs for all executions of `ccvvss ddiiffff' ).

CCVVSS CCOOMMMMAANNDD SSUUMMMMAARRYY #

 Here are brief descriptions of all the ccvvss commands:

 aadddd    Add a new file or directory to the repository, pending a `ccvvss
        ccoommmmiitt' on the same file.  Can only be done from within sources
        created by a previous `ccvvss cchheecckkoouutt' invocation.  Use `ccvvss iimmppoorrtt'
        to place whole new hierarchies of sources under ccvvss control.
        (Does not directly affect repository; changes working directory.)

 aaddmmiinn  Execute control functions on the source repository.  (Changes
        repository directly; uses working directory without changing it.)

 cchheecckkoouutt
        Make a working directory of source files for editing.  (Creates or
        changes working directory.)

 ccoommmmiitt Apply to the source repository changes, additions, and deletions
        from your working directory.  (Changes repository.)

 ddiiffff   Show differences between files in working directory and source
        repository, or between two revisions in source repository.  (Does
        not change either repository or working directory.)

 eexxppoorrtt Prepare copies of a set of source files for shipment off site.
        Differs from `ccvvss cchheecckkoouutt' in that no ccvvss administrative
        directories are created (and therefore `ccvvss ccoommmmiitt' cannot be
        executed from a directory prepared with `ccvvss eexxppoorrtt'), and a
        symbolic tag must be specified.  (Does not change repository;
        creates directory similar to working directories).

 hhiissttoorryy
        Show reports on ccvvss commands that you or others have executed on a
        particular file or directory in the source repository.  (Does not
        change repository or working directory.)  History logs are kept
        only if enabled by creation of the `$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//hhiissttoorryy'
        file; see ccvvss(55).

 iimmppoorrtt Incorporate a set of updates from off-site into the source
        repository, as a ``vendor branch''.  (Changes repository.)

 iinniitt   Initialize a repository by adding the CVSROOT subdirectory and
        some default control files. You must use this command or
        initialize the repository in some other way before you can use it.

 lloogg    Display log information.  (Does not change repository or working
        directory.)

 rrddiiffff  Prepare a collection of diffs as a patch file between two releases
        in the repository.  (Does not change repository or working
        directory.)

 rreelleeaassee
        Cancel a `ccvvss cchheecckkoouutt', abandoning any changes.  (Can delete
        working directory; no effect on repository.)

 rreemmoovvee Remove files from the source repository, pending a `ccvvss ccoommmmiitt' on
        the same files.  (Does not directly affect repository; changes
        working directory.)

 rrttaagg   Explicitly specify a symbolic tag for particular revisions of
        files in the source repository.  See also `ccvvss ttaagg'.  (Changes
        repository directly; does not require or affect working
        directory.)

 ssttaattuuss Show current status of files: latest version, version in working
        directory, whether working version has been edited and,
        optionally, symbolic tags in the RCS file.  (Does not change
        repository or working directory.)

 ttaagg    Specify a symbolic tag for files in the repository.  By default,
        tags the revisions that were last synchronized with your working
        directory.   (Changes repository directly; uses working directory
        without changing it.)

 uuppddaattee Bring your working directory up to date with changes from the
        repository.  Merges are performed automatically when possible; a
        warning is issued if manual resolution is required for conflicting
        changes.  (Changes working directory; does not change repository.)

CCOOMMMMOONN CCOOMMMMAANNDD OOPPTTIIOONNSS #

 This section describes the _c_o_m_m_a_n_d___o_p_t_i_o_n_s that are available across
 several ccvvss commands.  Not all commands support all of these options;
 each option is only supported for commands where it makes sense.
 However, when a command has one of these options you can count on the
 same meaning for the option as in other commands.  (Other command
 options, which are listed with the individual commands, may have
 different meanings from one ccvvss command to another.)  _W_a_r_n_i_n_g_: the
 hhiissttoorryy command is an exception; it supports many options that conflict
 even with these standard options.

 --DD _d_a_t_e___s_p_e_c
        Use the most recent revision no later than _d_a_t_e___s_p_e_c (a single
        argument, date description specifying a date in the past).  A wide
        variety of date formats are supported, in particular ISO
        ("1972-09-24 20:05") or Internet ("24 Sep 1972 20:05").  The
        _d_a_t_e___s_p_e_c is interpreted as being in the local timezone, unless a
        specific timezone is specified.  The specification is ``sticky''
        when you use it to make a private copy of a source file; that is,
        when you get a working file using --DD, ccvvss records the date you
        specified, so that further updates in the same directory will use
        the same date (unless you explicitly override it; see the
        description of the uuppddaattee command).  --DD is available with the
        cchheecckkoouutt, ddiiffff, hhiissttoorryy, eexxppoorrtt,  rrddiiffff, rrttaagg, and  uuppddaattee
        commands.  Examples of valid date specifications include:
                  11 mmoonntthh aaggoo
                  22 hhoouurrss aaggoo
                  440000000000 sseeccoonnddss aaggoo
                  llaasstt yyeeaarr
                  llaasstt MMoonnddaayy
                  yyeesstteerrddaayy
                  aa ffoorrttnniigghhtt aaggoo

33//3311//9922 1100::0000::0077 PPSSTT #

                  JJaannuuaarryy 2233,, 11998877 1100::0055ppmm

2222::0000 GGMMTT #

 --ff     When you specify a particular date or tag to ccvvss commands, they
        normally ignore files that do not contain the tag (or did not
        exist on the date) that you specified.  Use the --ff option if you
        want files retrieved even when there is no match for the tag or
        date.  (The most recent version is used in this situation.)  --ff is
        available with these commands: cchheecckkoouutt, eexxppoorrtt,  rrddiiffff, rrttaagg, and
        uuppddaattee.

 --kk _k_f_l_a_g
        Alter the default processing of keywords.  The --kk option is
        available with the aadddd, cchheecckkoouutt, ddiiffff, eexxppoorrtt,  rrddiiffff, and uuppddaattee
        commands.  Your _k_f_l_a_g specification is ``sticky'' when you use it
        to create a private copy of a source file; that is, when you use
        this option with the cchheecckkoouutt or uuppddaattee commands, ccvvss associates
        your selected _k_f_l_a_g with the file, and continues to use it with
        future uuppddaattee commands on the same file until you specify
        otherwise.

        Some of the more useful _k_f_l_a_gs are -ko and -kb (for binary files),
        and -kv which is useful for an eexxppoorrtt where you wish to retain
        keyword information after an iimmppoorrtt at some other site.

 --ll     Local; run only in current working directory, rather than
        recurring through subdirectories.   Available with the following
        commands: cchheecckkoouutt, ccoommmmiitt, ddiiffff,  eexxppoorrtt, rreemmoovvee, rrddiiffff, rrttaagg,
         ssttaattuuss, ttaagg, and uuppddaattee.  _W_a_r_n_i_n_g_: this is not the same as the
        overall `ccvvss --ll' option, which you can specify to the _l_e_f_t of a
        ccvvss command!

 --nn     Do _n_o_t run any cchheecckkoouutt/ccoommmmiitt/ttaagg/uuppddaattee program.  (A program can
        be specified to run on each of these activities, in the modules
        database; this option bypasses it.)  Available with the cchheecckkoouutt,
        ccoommmmiitt, eexxppoorrtt, and  rrttaagg commands.  _W_a_r_n_i_n_g_: this is not the same
        as the overall `ccvvss --nn' option, which you can specify to the _l_e_f_t
        of a ccvvss command!

 --PP     Prune (remove) directories that are empty after being updated, on
        cchheecckkoouutt, or uuppddaattee.  Normally, an empty directory (one that is
        void of revision-controlled files) is left alone.  Specifying --PP
        will cause these directories to be silently removed from your
        checked-out sources.  This does not remove the directory from the
        repository, only from your checked out copy.  Note that this
        option is implied by the --rr or --DD options of cchheecckkoouutt and eexxppoorrtt.

 --pp     Pipe the files retrieved from the repository to standard output,
        rather than writing them in the current directory.  Available with
        the cchheecckkoouutt and uuppddaattee commands.

 --rr _t_a_g Use the revision specified by the _t_a_g argument instead of the
        default ``head'' revision.  As well as arbitrary tags defined with
        the ttaagg or rrttaagg command, two special tags are always available:
        `HHEEAADD' refers to the most recent version available in the
        repository, and `BBAASSEE' refers to the revision you last checked out
        into the current working directory.

        The _t_a_g specification is ``sticky'' when you use this option with
        `ccvvss cchheecckkoouutt' or `ccvvss uuppddaattee' to make your own copy of a file:
        ccvvss remembers the _t_a_g and continues to use it on future uuppddaattee
        commands, until you specify otherwise.  _t_a_g can be either a
        symbolic or numeric tag.  Specifying the --qq global option along
        with the --rr command option is often useful, to suppress the
        warning messages when the RCS file does not contain the specified
        tag.  --rr is available with the cchheecckkoouutt, ccoommmmiitt, ddiiffff,  hhiissttoorryy,
        eexxppoorrtt,  rrddiiffff, rrttaagg, and uuppddaattee commands.  _W_a_r_n_i_n_g_: this is not
        the same as the overall `ccvvss --rr' option, which you can specify to
        the _l_e_f_t of a ccvvss command!

 --tt _i_d  Expand the RCS identifier specified by the _i_d argument in addition
        to the default ``Id'' identifier.  --tt is available with the
        cchheecckkoouutt, eexxppoorrtt, and uuppddaattee commands.  If the identifier name is
        specified as ``-'', no additional identifiers will be expanded.

CCVVSS CCOOMMMMAANNDDSS #

 Here (finally) are details on all the ccvvss commands and the options each
 accepts.  The summary lines at the top of each command's description
 highlight three kinds of things:

     Command Options and Arguments
           Special options are described in detail below; common command
           options may appear only in the summary line.

     Working Directory, or Repository?
           Some ccvvss commands require a working directory to operate; some
           require a repository.  Also, some commands _c_h_a_n_g_e the
           repository, some change the working directory, and some change
           nothing.

     Synonyms
           Many commands have synonyms, which you may find easier to
           remember (or type) than the principal name.

 aadddd [--kk _k_f_l_a_g] [--mm ''_m_e_s_s_a_g_e''] _f_i_l_e_s_._._.
           _R_e_q_u_i_r_e_s_: repository, working directory.
           _C_h_a_n_g_e_s_: working directory.
           _S_y_n_o_n_y_m_: nneeww
           Use the aadddd command to create a new file or directory in the
           source repository.  The files or directories specified with aadddd
           must already exist in the current directory (which must have
           been created with the cchheecckkoouutt command).  To add a whole new
           directory hierarchy to the source repository (for example,
           files received from a third-party vendor), use the `ccvvss iimmppoorrtt'
           command instead.

           If the argument to `ccvvss aadddd' refers to an immediate sub-
           directory, the directory is created at the correct place in the
           source repository, and the necessary ccvvss administration files
           are created in your working directory.  If the directory
           already exists in the source repository, `ccvvss aadddd' still
           creates the administration files in your version of the
           directory.  This allows you to use `ccvvss aadddd' to add a
           particular directory to your private sources even if someone
           else created that directory after your cchheecckkoouutt of the sources.
           You can do the following:

                     eexxaammppllee%% mmkkddiirr nneeww__ddiirreeccttoorryy
                     eexxaammppllee%% ccvvss aadddd nneeww__ddiirreeccttoorryy
                     eexxaammppllee%% ccvvss uuppddaattee nneeww__ddiirreeccttoorryy

           An alternate approach using `ccvvss uuppddaattee' might be:

                     eexxaammppllee%% ccvvss uuppddaattee --dd nneeww__ddiirreeccttoorryy

           (To add _a_n_y _a_v_a_i_l_a_b_l_e new directories to your working
           directory, it's probably simpler to use `ccvvss cchheecckkoouutt' or `ccvvss
           uuppddaattee --dd'.)

           The added files are not placed in the source repository until
           you use `ccvvss ccoommmmiitt' to make the change permanent.  Doing a
           `ccvvss aadddd' on a file that was removed with the `ccvvss rreemmoovvee'
           command will resurrect the file, if no `ccvvss ccoommmmiitt' command
           intervened.

           You will have the opportunity to specify a logging message, as
           usual, when you use `ccvvss ccoommmmiitt' to make the new file
           permanent.  If you'd like to have another logging message
           associated with just _c_r_e_a_t_i_o_n of the file (for example, to
           describe the file's purpose), you can specify it with the `--mm
           _m_e_s_s_a_g_e' option to the aadddd command.

           The `--kk kkffllaagg' option specifies the default way that this file
           will be checked out.  The `kkffllaagg' argument is stored in the RCS
           file and can be changed with `ccvvss aaddmmiinn'.  Specifying `--kkoo' is
           useful for checking in binaries that shouldn't have keywords
           expanded.

 aaddmmiinn [_r_c_s_-_o_p_t_i_o_n_s] _f_i_l_e_s_._._.
           _R_e_q_u_i_r_e_s_: repository, working directory.
           _C_h_a_n_g_e_s_: repository.
           _S_y_n_o_n_y_m_: rrccss
           This is the ccvvss interface to assorted administrative
           facilities, similar to rrccss(11).  This command works recursively,
           so extreme care should be used.

 cchheecckkoouutt [ooppttiioonnss] _m_o_d_u_l_e_s...
           _R_e_q_u_i_r_e_s_: repository.
           _C_h_a_n_g_e_s_: working directory.
           _S_y_n_o_n_y_m_s_: ccoo, ggeett
           Make a working directory containing copies of the source files
           specified by _m_o_d_u_l_e_s.  You must execute `ccvvss cchheecckkoouutt' before
           using most of the other ccvvss commands, since most of them
           operate on your working directory.

           _m_o_d_u_l_e_s are either symbolic names (themselves defined as the
           module `mmoodduulleess' in the source repository; see ccvvss(55)) for some
           collection of source directories and files, or paths to
           directories or files in the repository.

           Depending on the _m_o_d_u_l_e_s you specify, cchheecckkoouutt may recursively
           create directories and populate them with the appropriate
           source files.  You can then edit these source files at any time
           (regardless of whether other software developers are editing
           their own copies of the sources); update them to include new
           changes applied by others to the source repository; or commit
           your work as a permanent change to the repository.

           Note that cchheecckkoouutt is used to create directories.  The top-
           level directory created is always added to the directory where
           cchheecckkoouutt is invoked, and usually has the same name as the
           specified _m_o_d_u_l_e.  In the case of a _m_o_d_u_l_e alias, the created
           sub-directory may have a different name, but you can be sure
           that it will be a sub-directory, and that cchheecckkoouutt will show
           the relative path leading to each file as it is extracted into
           your private work area (unless you specify the --QQ global
           option).

           Running `ccvvss cchheecckkoouutt' on a directory that was already built by
           a prior cchheecckkoouutt is also permitted, and has the same effect as
           specifying the --dd option to the uuppddaattee command described below.

           The _o_p_t_i_o_n_s permitted with `ccvvss cchheecckkoouutt' include the standard
           command options --PP, --ff,  --kk _k_f_l_a_g , --ll, --nn, --pp,  --rr _t_a_g, and --DD
           _d_a_t_e.

           In addition to those, you can use these special command options
           with cchheecckkoouutt:

           Use the --AA option to reset any sticky tags, dates, or --kk
           options.  (If you get a working file using one of the --rr, --DD,
           or --kk options, ccvvss remembers the corresponding tag, date, or
           _k_f_l_a_g and continues using it on future updates; use the --AA
           option to make ccvvss forget these specifications, and retrieve
           the ``head'' version of the file).

           The --jj _b_r_a_n_c_h option merges the changes made between the
           resulting revision and the revision that it is based on (e.g.,
           if the tag refers to a branch, ccvvss will merge all changes made
           in that branch into your working file).

           With two --jj options, ccvvss will merge in the changes between the
           two respective revisions.  This can be used to ``remove'' a
           certain delta from your working file.

           In addition, each --jj option can contain on optional date
           specification which, when used with branches, can limit the
           chosen revision to one within a specific date.  An optional
           date is specified by adding a colon (:) to the tag.  An example
           might be what `ccvvss iimmppoorrtt' tells you to do when you have just
           imported sources that have conflicts with local changes:

                     eexxaammppllee%% ccvvss cchheecckkoouutt --jjTTAAGG::yyeesstteerrddaayy --jjTTAAGG mmoodduullee

           Use the --NN option with `--dd _d_i_r' to avoid shortening module
           paths in your working directory.   (Normally, ccvvss shortens
           paths as much as possible when you specify an explicit target
           directory.)

           Use the --cc option to copy the module file, sorted, to the
           standard output, instead of creating or modifying any files or
           directories in your working directory.

           Use the --dd _d_i_r option to create a directory called _d_i_r for the
           working files, instead of using the module name.  Unless you
           also use --NN, the paths created under _d_i_r will be as short as
           possible.

           Use the --ss option to display per-module status information
           stored with the --ss option within the modules file.

 ccoommmmiitt [--ffllnnRR] [--mm '_l_o_g___m_e_s_s_a_g_e' | --FF _f_i_l_e] [--rr _r_e_v_i_s_i_o_n] [_f_i_l_e_s_._._.]
           _R_e_q_u_i_r_e_s_: working directory, repository.
           _C_h_a_n_g_e_s_: repository.
           _S_y_n_o_n_y_m_: ccii
           Use `ccvvss ccoommmmiitt' when you want to incorporate changes from your
           working source files into the general source repository.

           If you don't specify particular _f_i_l_e_s to commit, all of the
           files in your working current directory are examined.  ccoommmmiitt
           is careful to change in the repository only those files that
           you have really changed.  By default (or if you explicitly
           specify the --RR option), files in subdirectories are also
           examined and committed if they have changed; you can use the --ll
           option to limit ccoommmmiitt to the current directory only.
           Sometimes you may want to force a file to be committed even
           though it is unchanged; this is achieved with the --ff flag,
           which also has the effect of disabling recursion (you can turn
           it back on with --RR of course).

           ccoommmmiitt verifies that the selected files are up to date with the
           current revisions in the source repository; it will notify you,
           and exit without committing, if any of the specified files must
           be made current first with `ccvvss uuppddaattee'.  ccoommmmiitt does not call
           the uuppddaattee command for you, but rather leaves that for you to
           do when the time is right.

           When all is well, an editor is invoked to allow you to enter a
           log message that will be written to one or more logging
           programs and placed in the source repository file.  You can
           instead specify the log message on the command line with the --mm
           option, thus suppressing the editor invocation, or use the --FF
           option to specify that the argument _f_i_l_e contains the log
           message.

           At ccoommmmiitt a unique commitid is placed in the rcs file inside
           the repository.  All files committed at once get the same
           commitid.  The commitid can be retrieved with the lloogg and
           ssttaattuuss commands.

           The --rr option can be used to commit to a particular symbolic or
           numeric revision.  For example, to bring all your files up to
           the revision ``3.0'' (including those that haven't changed),
           you might do:

                     eexxaammppllee%% ccvvss ccoommmmiitt --rr33..00

           ccvvss will only allow you to commit to a revision that is on the
           main trunk (a revision with a single dot).  However, you can
           also commit to a branch revision (one that has an even number
           of dots) with the --rr option.  To create a branch revision, one
           typically use the --bb option of the rrttaagg or ttaagg commands.  Then,
           either cchheecckkoouutt or uuppddaattee can be used to base your sources on
           the newly created branch.  From that point on, all ccoommmmiitt
           changes made within these working sources will be automatically
           added to a branch revision, thereby not perturbing main-line
           development in any way.  For example, if you had to create a
           patch to the 1.2 version of the product, even though the 2.0
           version is already under development, you might do:

                     eexxaammppllee%% ccvvss rrttaagg --bb --rrFFCCSS11__22 FFCCSS11__22__PPaattcchh pprroodduucctt__mmoodduullee
                     eexxaammppllee%% ccvvss cchheecckkoouutt --rrFFCCSS11__22__PPaattcchh pprroodduucctt__mmoodduullee
                     eexxaammppllee%% ccdd pprroodduucctt__mmoodduullee
                     [[[[ hhaacckk aawwaayy ]]]]
                     eexxaammppllee%% ccvvss ccoommmmiitt

           Say you have been working on some extremely experimental
           software, based on whatever revision you happened to checkout
           last week.  If others in your group would like to work on this
           software with you, but without disturbing main-line
           development, you could commit your change to a new branch.
           Others can then checkout your experimental stuff and utilize
           the full benefit of ccvvss conflict resolution.  The scenario
           might look like:

                     eexxaammppllee%% ccvvss ttaagg --bb EEXXPPRR11
                     eexxaammppllee%% ccvvss uuppddaattee --rrEEXXPPRR11
                     [[[[ hhaacckk aawwaayy ]]]]
                     eexxaammppllee%% ccvvss ccoommmmiitt

           Others would simply do `ccvvss cchheecckkoouutt --rrEEXXPPRR11 wwhhaatteevveerr__mmoodduullee'
           to work with you on the experimental change.

 ddiiffff [--kkll] [_r_c_s_d_i_f_f___o_p_t_i_o_n_s] [[--rr _r_e_v_1 | --DD _d_a_t_e_1] [--rr _r_e_v_2 | --DD _d_a_t_e_2]]
 [_f_i_l_e_s_._._.]
           _R_e_q_u_i_r_e_s_: working directory, repository.
           _C_h_a_n_g_e_s_: nothing.
           You can compare your working files with revisions in the source
           repository, with the `ccvvss ddiiffff' command.  If you don't specify
           a particular revision, your files are compared with the
           revisions they were based on.  You can also use the standard
           ccvvss command option --rr to specify a particular revision to
           compare your files with.  Finally, if you use --rr twice, you can
           see differences between two revisions in the repository.  You
           can also specify --DD options to diff against a revision in the
           past.  The --rr and --DD options can be mixed together with at most
           two options ever specified.

           See rrccssddiiffff(11) for a list of other accepted options.

           If you don't specify any files, ddiiffff will display differences
           for all those files in the current directory (and its
           subdirectories, unless you use the standard option --ll) that
           differ from the corresponding revision in the source repository
           (i.e. files that _y_o_u have changed), or that differ from the
           revision specified.

 eexxppoorrtt [-ffllNNnnQQqq] --rr _r_e_v|--DD _d_a_t_e [--dd _d_i_r] [--kk _k_f_l_a_g] _m_o_d_u_l_e...
           _R_e_q_u_i_r_e_s_: repository.
           _C_h_a_n_g_e_s_: current directory.
           This command is a variant of `ccvvss cchheecckkoouutt'; use it when you
           want a copy of the source for _m_o_d_u_l_e without the ccvvss
           administrative directories.  For example, you might use `ccvvss
           eexxppoorrtt' to prepare source for shipment off-site.  This command
           _r_e_q_u_i_r_e_s that you specify a date or tag (with --DD or --rr), so
           that you can count on reproducing the source you ship to
           others.

           The only non-standard options are `--dd _d_i_r' (write the source
           into directory _d_i_r) and `--NN' (don't shorten module paths).
           These have the same meanings as the same options in `ccvvss
           cchheecckkoouutt'.

           The --kkvv option is useful when eexxppoorrtt is used.  This causes any
           keywords to be expanded such that an iimmppoorrtt done at some other
           site will not lose the keyword revision information.  Other
           _k_f_l_a_gs may be used with `ccvvss eexxppoorrtt' and are described in
           ccoo(11).

 hhiissttoorryy [--_r_e_p_o_r_t] [--_f_l_a_g_s] [--_o_p_t_i_o_n_s _a_r_g_s] [_f_i_l_e_s...]
           _R_e_q_u_i_r_e_s_: the file `$$CCVVSSRROOOOTT//CCVVSSRROOOOTT//hhiissttoorryy'
           _C_h_a_n_g_e_s_: nothing.
           ccvvss keeps a history file that tracks each use of the cchheecckkoouutt,
           ccoommmmiitt, rrttaagg, uuppddaattee, and rreelleeaassee commands.  You can use `ccvvss
           hhiissttoorryy' to display this information in various formats.

           _W_a_r_n_i_n_g_: `ccvvss hhiissttoorryy' uses `--ff', `--ll', `--nn', and `--pp' in ways
           that conflict with the descriptions in COMMON COMMAND OPTIONS.

           Several options (shown above as --_r_e_p_o_r_t) control what kind of
           report is generated:

             --cc  Report on each time ccoommmmiitt was used (i.e., each time the
           repository was modified).

             --mm _m_o_d_u_l_e
           Report on a particular _m_o_d_u_l_e.  (You can meaningfully use --mm
           more than once on the command line.)

             --oo  Report on checked-out modules.

             --TT  Report on all tags.

             --xx _t_y_p_e
           Extract a particular set of record types _X from the ccvvss
           history.  The types are indicated by single letters, which you
           may specify in combination.  Certain commands have a single
           record type: cchheecckkoouutt (type `O'), rreelleeaassee (type `F'), and rrttaagg
           (type `T').  One of four record types may result from an
           uuppddaattee: `W', when the working copy of a file is deleted during
           update (because it was gone from the repository); `U', when a
           working file was copied from the repository; `G', when a merge
           was necessary and it succeeded; and 'C', when a merge was
           necessary but collisions were detected (requiring manual
           merging).  Finally, one of three record types results from
           ccoommmmiitt: `M', when a file was modified; `A', when a file is
           first added; and `R', when a file is removed.

             --ee  Everything (all record types); equivalent to specifying
           `--xxMMAACCFFRROOGGWWUUTT'.

             --zz _z_o_n_e
           Use time zone _z_o_n_e when outputting history records.  The zone
           name LLTT stands for local time; numeric offsets stand for hours
           and minutes ahead of UTC.  For example, ++00553300 stands for 5
           hours and 30 minutes ahead of (i.e. east of) UTC.

      The options shown as --_f_l_a_g_s constrain the report without requiring
      option arguments:

             --aa  Show data for all users (the default is to show data only for
           the user executing `ccvvss hhiissttoorryy').

             --ll  Show last modification only.

             --ww  Show only the records for modifications done from the same
           working directory where `ccvvss hhiissttoorryy' is executing.

      The options shown as --_o_p_t_i_o_n_s _a_r_g_s constrain the report based on an
      argument:

             --bb _s_t_r
           Show data back to a record containing the string _s_t_r in either
           the module name, the file name, or the repository path.

             --DD _d_a_t_e
           Show data since _d_a_t_e.

             --pp _r_e_p_o_s_i_t_o_r_y
           Show data for a particular source repository (you can specify
           several --pp options on the same command line).

             --rr _r_e_v
           Show records referring to revisions since the revision or tag
           named _r_e_v appears in individual RCS files.  Each RCS file is
           searched for the revision or tag.

             --tt _t_a_g
           Show records since tag _t_a_g was last added to the history file.
           This differs from the --rr flag above in that it reads only the
           history file, not the RCS files, and is much faster.

             --uu _n_a_m_e
           Show records for user _n_a_m_e.

 iimmppoorrtt [--_o_p_t_i_o_n_s] _r_e_p_o_s_i_t_o_r_y _v_e_n_d_o_r_t_a_g _r_e_l_e_a_s_e_t_a_g...
           _R_e_q_u_i_r_e_s_: Repository, source distribution directory.
           _C_h_a_n_g_e_s_: repository.
           Use `ccvvss iimmppoorrtt' to incorporate an entire source distribution
           from an outside source (e.g., a source vendor) into your source
           repository directory.  You can use this command both for
           initial creation of a repository, and for wholesale updates to
           the module form the outside source.

           The _r_e_p_o_s_i_t_o_r_y argument gives a directory name (or a path to a
           directory) under the CVS root directory for repositories; if
           the directory did not exist, iimmppoorrtt creates it.

           When you use iimmppoorrtt for updates to source that has been
           modified in your source repository (since a prior iimmppoorrtt), it
           will notify you of any files that conflict in the two branches
           of development; use `ccvvss cchheecckkoouutt --jj' to reconcile the
           differences, as iimmppoorrtt instructs you to do.

           By default, certain file names are ignored during `ccvvss iimmppoorrtt':
           names associated with CVS administration, or with other common
           source control systems; common names for patch files, object
           files, archive files, and editor backup files; and other names
           that are usually artifacts of assorted utilities.  For an up to
           date list of ignored file names, see the Cederqvist manual (as
           described in the SEE ALSO section of this manpage).

           The outside source is saved in a first-level branch, by default
           `11..11..11'.  Updates are leaves of this branch; for example, files
           from the first imported collection of source will be revision
           `11..11..11..11', then files from the first imported update will be
           revision `11..11..11..22', and so on.

           At least three arguments are required.  _r_e_p_o_s_i_t_o_r_y is needed to
           identify the collection of source.  _v_e_n_d_o_r_t_a_g is a tag for the
           entire branch (e.g., for `11..11..11').  You must also specify at
           least one _r_e_l_e_a_s_e_t_a_g to identify the files at the leaves
           created each time you execute `ccvvss iimmppoorrtt'.

           One of the standard ccvvss command options is available: --mm
           _m_e_s_s_a_g_e.  If you do not specify a logging message with --mm, your
           editor is invoked (as with ccoommmmiitt) to allow you to enter one.

           There are three additional special options.

           Use `--dd' to specify that each file's time of last modification
           should be used for the checkin date and time.

           Use `--bb _b_r_a_n_c_h' to specify a first-level branch other than
           `11..11..11'.

           Use `--II _n_a_m_e' to specify file names that should be ignored
           during iimmppoorrtt.  You can use this option repeatedly.  To avoid
           ignoring any files at all (even those ignored by default),
           specify `--II !!'.

 lloogg [--ll] _r_l_o_g_-_o_p_t_i_o_n_s _[_f_i_l_e_s...]
           _R_e_q_u_i_r_e_s_: repository, working directory.
           _C_h_a_n_g_e_s_: nothing.
           _S_y_n_o_n_y_m_: rrlloogg
           Display log information for _f_i_l_e_s.  Among the more useful
           options are --hh to display only the header (including tag
           definitions, but omitting most of the full log); --rr to select
           logs on particular revisions or ranges of revisions; and --dd to
           select particular dates or date ranges.  See rrlloogg(11) for full
           explanations.  This command is recursive by default, unless the
           --ll option is specified.

 rrddiiffff [--_f_l_a_g_s] [--VV _v_n] [--rr _t|--DD _d [--rr _t_2|--DD _d_2]] _m_o_d_u_l_e_s_._._.
           _R_e_q_u_i_r_e_s_: repository.
           _C_h_a_n_g_e_s_: nothing.
           _S_y_n_o_n_y_m_: ppaattcchh
           Builds a Larry Wall format ppaattcchh(11) file between two releases,
           that can be fed directly into the ppaattcchh program to bring an old
           release up-to-date with the new release.  (This is one of the
           few ccvvss commands that operates directly from the repository,
           and doesn't require a prior cchheecckkoouutt.) The diff output is sent
           to the standard output device.  You can specify (using the
           standard --rr and --DD options) any combination of one or two
           revisions or dates.  If only one revision or date is specified,
           the patch file reflects differences between that revision or
           date and the current ``head'' revisions in the RCS file.

           Note that if the software release affected is contained in more
           than one directory, then it may be necessary to specify the --pp
           option to the ppaattcchh command when patching the old sources, so
           that ppaattcchh is able to find the files that are located in other
           directories.

           The standard option _f_l_a_g_s --ff, and --ll are available with this
           command.  There are also several special options flags:

           If you use the --ss option, no patch output is produced.
           Instead, a summary of the changed or added files between the
           two releases is sent to the standard output device.  This is
           useful for finding out, for example, which files have changed
           between two dates or revisions.

           If you use the --tt option, a diff of the top two revisions is
           sent to the standard output device.  This is most useful for
           seeing what the last change to a file was.

           If you use the --uu option, the patch output uses the newer
           ``unidiff'' format for context diffs.

           You can use --cc to explicitly specify the `ddiiffff --cc' form of
           context diffs (which is the default), if you like.

 rreelleeaassee [--ddQQqq] _m_o_d_u_l_e_s...
           _R_e_q_u_i_r_e_s_: Working directory.
           _C_h_a_n_g_e_s_: Working directory, history log.
           This command is meant to safely cancel the effect of `ccvvss
           cchheecckkoouutt'.  Since ccvvss doesn't lock files, it isn't strictly
           necessary to use this command.  You can always simply delete
           your working directory, if you like; but you risk losing
           changes you may have forgotten, and you leave no trace in the
           ccvvss history file that you've abandoned your checkout.

           Use `ccvvss rreelleeaassee' to avoid these problems.  This command checks
           that no un-committed changes are present; that you are
           executing it from immediately above, or inside, a ccvvss working
           directory; and that the repository recorded for your files is
           the same as the repository defined in the module database.

           If all these conditions are true, `ccvvss rreelleeaassee' leaves a record
           of its execution (attesting to your intentionally abandoning
           your checkout) in the ccvvss history log.

           You can use the --dd flag to request that your working copies of
           the source files be deleted if the rreelleeaassee succeeds.

 rreemmoovvee [--llRR] [_f_i_l_e_s_._._.]
           _R_e_q_u_i_r_e_s_: Working directory.
           _C_h_a_n_g_e_s_: Working directory.
           _S_y_n_o_n_y_m_s_: rrmm, ddeelleettee
           Use this command to declare that you wish to remove _f_i_l_e_s from
           the source repository.  Like most ccvvss commands, `ccvvss rreemmoovvee'
           works on files in your working directory, not directly on the
           repository.  As a safeguard, it also requires that you first
           erase the specified files from your working directory.

           The files are not actually removed until you apply your changes
           to the repository with ccoommmmiitt; at that point, the corresponding
           RCS files in the source repository are _m_o_v_e_d into the `AAttttiicc'
           directory (also within the source repository).

           This command is recursive by default, scheduling all physically
           removed files that it finds for removal by the next ccoommmmiitt.
           Use the --ll option to avoid this recursion, or just specify that
           actual files that you wish remove to consider.

 rrttaagg [--ffaallnnRRQQqq] [--bb] [--dd] [--rr _t_a_g | --DD _d_a_t_e] _s_y_m_b_o_l_i_c___t_a_g _m_o_d_u_l_e_s_._._.
           _R_e_q_u_i_r_e_s_: repository.
           _C_h_a_n_g_e_s_: repository.
           _S_y_n_o_n_y_m_: rrffrreeeezzee
           You can use this command to assign symbolic tags to particular,
           explicitly specified source versions in the repository.  `ccvvss
           rrttaagg' works directly on the repository contents (and requires
           no prior cchheecckkoouutt).  Use `ccvvss ttaagg' instead, to base the
           selection of versions to tag on the contents of your working
           directory.

           In general, tags (often the symbolic names of software
           distributions) should not be removed, but the --dd option is
           available as a means to remove completely obsolete symbolic
           names if necessary (as might be the case for an Alpha release,
           say).

           `ccvvss rrttaagg' will not move a tag that already exists.  With the
           --FF option, however, `ccvvss rrttaagg' will re-locate any instance of
           _s_y_m_b_o_l_i_c___t_a_g that already exists on that file to the new
           repository versions.  Without the --FF option, attempting to use
           `ccvvss rrttaagg' to apply a tag that already exists on that file will
           produce an error message.

           The --bb option makes the tag a ``branch'' tag, allowing
           concurrent, isolated development.  This is most useful for
           creating a patch to a previously released software
           distribution.

           You can use the standard --rr and --DD options to tag only those
           files that already contain a certain tag.  This method would be
           used to rename a tag: tag only the files identified by the old
           tag, then delete the old tag, leaving the new tag on exactly
           the same files as the old tag.

           rrttaagg executes recursively by default, tagging all
           subdirectories of _m_o_d_u_l_e_s you specify in the argument.  You can
           restrict its operation to top-level directories with the
           standard --ll option; or you can explicitly request recursion
           with --RR.

           The modules database can specify a program to execute whenever
           a tag is specified; a typical use is to send electronic mail to
           a group of interested parties.  If you want to bypass that
           program, use the standard --nn option.

           Use the --aa option to have rrttaagg look in the `AAttttiicc' for removed
           files that contain the specified tag.  The tag is removed from
           these files, which makes it convenient to re-use a symbolic tag
           as development continues (and files get removed from the up-
           coming distribution).

 ssttaattuuss [--llRRqqQQ] [--vv] [_f_i_l_e_s...]
           _R_e_q_u_i_r_e_s_: working directory, repository.
           _C_h_a_n_g_e_s_: nothing.
           Display a brief report on the current status of _f_i_l_e_s with
           respect to the source repository, including any ``sticky''
           tags, dates, or --kk options.  (``Sticky'' options will restrict
           how `ccvvss uuppddaattee' operates until you reset them; see the
           description of `ccvvss uuppddaattee --AA......'.)

           You can also use this command to anticipate the potential
           impact of a `ccvvss uuppddaattee' on your working source directory.  If
           you do not specify any _f_i_l_e_s explicitly, reports are shown for
           all files that ccvvss has placed in your working directory.  You
           can limit the scope of this search to the current directory
           itself (not its subdirectories) with the standard --ll option
           flag; or you can explicitly request recursive status reports
           with the --RR option.

           The --vv option causes the symbolic tags for the RCS file to be
           displayed as well.

 ttaagg [--llQQqqRR] [--FF] [--bb] [--dd] [--rr _t_a_g | --DD _d_a_t_e] [--ff] _s_y_m_b_o_l_i_c___t_a_g
 [_f_i_l_e_s...]
           _R_e_q_u_i_r_e_s_: working directory, repository.
           _C_h_a_n_g_e_s_: repository.
           _S_y_n_o_n_y_m_: ffrreeeezzee
           Use this command to assign symbolic tags to the nearest
           repository versions to your working sources.  The tags are
           applied immediately to the repository, as with rrttaagg.

           One use for tags is to record a ``snapshot'' of the current
           sources when the software freeze date of a project arrives.  As
           bugs are fixed after the freeze date, only those changed
           sources that are to be part of the release need be re-tagged.

           The symbolic tags are meant to permanently record which
           revisions of which files were used in creating a software
           distribution.  The cchheecckkoouutt, eexxppoorrtt and uuppddaattee commands allow
           you to extract an exact copy of a tagged release at any time in
           the future, regardless of whether files have been changed,
           added, or removed since the release was tagged.

           You can use the standard --rr and --DD options to tag only those
           files that already contain a certain tag.  This method would be
           used to rename a tag: tag only the files identified by the old
           tag, then delete the old tag, leaving the new tag on exactly
           the same files as the old tag.

           Specifying the --ff flag in addition to the --rr or --DD flags will
           tag those files named on the command line even if they do not
           contain the old tag or did not exist on the specified date.

           By default (without a --rr or --DD flag) the versions to be tagged
           are supplied implicitly by the ccvvss records of your working
           files' history rather than applied explicitly.

           If you use `ccvvss ttaagg --dd _s_y_m_b_o_l_i_c___t_a_g......', the symbolic tag you
           specify is _d_e_l_e_t_e_d instead of being added.  _W_a_r_n_i_n_g: Be very
           certain of your ground before you delete a tag; doing this
           effectively discards some historical information, which may
           later turn out to have been valuable.

           `ccvvss ttaagg' will not move a tag that already exists.  With the --FF
           option, however, `ccvvss ttaagg' will re-locate any instance of
           _s_y_m_b_o_l_i_c___t_a_g that already exists on that file to the new
           repository versions.  Without the --FF option, attempting to use
           `ccvvss ttaagg' to apply a tag that already exists on that file will
           produce an error message.

           The --bb option makes the tag a ``branch'' tag, allowing
           concurrent, isolated development.  This is most useful for
           creating a patch to a previously released software
           distribution.

           Normally, ttaagg executes recursively through subdirectories; you
           can prevent this by using the standard --ll option, or specify
           the recursion explicitly by using --RR.

 uuppddaattee [--AACCddffllPPppQQqqRR] [--dd] [--rr _t_a_g|--DD _d_a_t_e] _f_i_l_e_s_._._.
           _R_e_q_u_i_r_e_s_: repository, working directory.
           _C_h_a_n_g_e_s_: working directory.
           After you've run cchheecckkoouutt to create your private copy of source
           from the common repository, other developers will continue
           changing the central source.  From time to time, when it is
           convenient in your development process, you can use the uuppddaattee
           command from within your working directory to reconcile your
           work with any revisions applied to  the source repository since
           your last cchheecckkoouutt or uuppddaattee.

           uuppddaattee keeps you informed of its progress by printing a line
           for each file, prefaced with one of the characters `UU PP AA RR MM CC
           ??' to indicate the status of the file:

 UU _f_i_l_e    The file has been brought _u_p _t_o _d_a_t_e with respect to the
           repository.  This is done for any file that exists in the
           repository but not in your source, and for files that you
           haven't changed but are not the most recent versions available
           in the repository.

 PP _f_i_l_e    As `UU', but instead of transferring the entire file a patch
           containing the required changes were sent.

 AA _f_i_l_e    The file has been _a_d_d_e_d to your private copy of the sources,
           and will be added to the source repository when you run `ccvvss
           ccoommmmiitt' on the file.  This is a reminder to you that the file
           needs to be committed.

 RR _f_i_l_e    The file has been _r_e_m_o_v_e_d from your private copy of the
           sources, and will be removed from the source repository when
           you run `ccvvss ccoommmmiitt' on the file.  This is a reminder to you
           that the file needs to be committed.

 MM _f_i_l_e    The file has been _m_o_d_i_f_i_e_d in your working directory.  `MM' can
           indicate one of two states for a file you're working on: either
           there were no modifications to the same file in the repository,
           so that your file remains as you last saw it; or there were
           modifications in the repository as well as in your copy, but
           they were _m_e_r_g_e_d successfully, without conflict, in your
           working directory.

 CC _f_i_l_e    A _c_o_n_f_l_i_c_t has been detected while trying to merge your changes
           to _f_i_l_e with changes from the source repository.  _f_i_l_e (the
           copy in your working directory) is now the result of merging
           the two versions; an unmodified copy of your file is also in
           your working directory, with the name `..##_f_i_l_e.._v_e_r_s_i_o_n', where
           _v_e_r_s_i_o_n is the revision that your modified file started from.
           (Note that some systems automatically purge files that begin
           with  `..##' if they have not been accessed for a few days.  If
           you intend to keep a copy of your original file, it is a very
           good idea to rename it.)

 ?? _f_i_l_e    _f_i_l_e is in your working directory, but does not correspond to
           anything in the source repository, and is not in the list of
           files for ccvvss to ignore (see the description of the --II option).


      Use the --AA option to reset any sticky tags, dates, or --kk options.
      (If you get a working copy of a file by using one of the --rr, --DD, or
      --kk options, ccvvss remembers the corresponding tag, date, or _k_f_l_a_g and
      continues using it on future updates; use the --AA option to make ccvvss
      forget these specifications, and retrieve the ``head'' version of
      the file).

      The --jj_b_r_a_n_c_h option merges the changes made between the resulting
      revision and the revision that it is based on (e.g., if the tag
      refers to a branch, ccvvss will merge all changes made in that branch
      into your working file).

      With two --jj options, ccvvss will merge in the changes between the two
      respective revisions.  This can be used to ``remove'' a certain
      delta from your working file.  E.g., If the file foo.c is based on
      revision 1.6 and I want to remove the changes made between 1.3 and
      1.5, I might do:

                eexxaammppllee%% ccvvss uuppddaattee --jj11..55 --jj11..33 ffoooo..cc   ## nnoottee tthhee oorrddeerr......

      In addition, each --jj option can contain on optional date
      specification which, when used with branches, can limit the chosen
      revision to one within a specific date.  An optional date is
      specified by adding a colon (:) to the tag.

                --jjSSyymmbboolliicc__TTaagg::DDaattee__SSppeecciiffiieerr

      Use the --dd option to create any directories that exist in the
      repository if they're missing from the working directory.
      (Normally, update acts only on directories and files that were
      already enrolled in your working directory.)  This is useful for
      updating directories that were created in the repository since the
      initial cchheecckkoouutt; but it has an unfortunate side effect.  If you
      deliberately avoided certain directories in the repository when you
      created your working directory (either through use of a module name
      or by listing explicitly the files and directories you wanted on the
      command line), then updating with --dd will create those directories,
      which may not be what you want.

      Use --II _n_a_m_e to ignore files whose names match _n_a_m_e (in your working
      directory) during the update.  You can specify --II more than once on
      the command line to specify several files to ignore.  By default,
      uuppddaattee ignores files whose names match certain patterns; for an up
      to date list of ignored file names, see the Cederqvist manual (as
      described in the SEE ALSO section of this manpage).

      Use `--II !!' to avoid ignoring any files at all.

      Use the `--CC' option to overwrite locally modified files with clean
      copies from the repository (the modified file is saved in
      `..##_f_i_l_e.._r_e_v_i_s_i_o_n', however).

      The standard ccvvss command options --ff, --kk, --ll, --PP, --pp, and --rr are also
      available with uuppddaattee.

FFIILLEESS #

 For more detailed information on ccvvss supporting files, see ccvvss(55).

 _F_i_l_e_s _i_n _h_o_m_e _d_i_r_e_c_t_o_r_i_e_s_:

 .cvsrc The ccvvss initialisation file.  Lines in this file can be used to
        specify default options for each ccvvss command.  For example the
        line `ddiiffff --cc' will ensure that `ccvvss ddiiffff' is always passed the --cc
        option in addition to any other options passed on the command
        line.

 .cvswrappers
        Specifies wrappers to be used in addition to those specified in
        the CVSROOT/cvswrappers file in the repository.

 _F_i_l_e_s _i_n _w_o_r_k_i_n_g _d_i_r_e_c_t_o_r_i_e_s_:

 CVS    A directory of ccvvss administrative files.  _D_o _n_o_t _d_e_l_e_t_e_.

 CVS/Entries
        List and status of files in your working directory.

 CVS/Entries.Backup
        A backup of `CCVVSS//EEnnttrriieess'.

 CVS/Entries.Static
        Flag: do not add more entries on `ccvvss uuppddaattee'.

 CVS/Root
        Pathname to the repository ( CVSROOT ) location at the time of
        checkout.  This file is used instead of the CVSROOT environment
        variable if the environment variable is not set.  A warning
        message will be issued when the contents of this file and the
        CVSROOT environment variable differ.  The file may be over-ridden
        by the presence of the CVS_IGNORE_REMOTE_ROOT environment
        variable.

 CVS/Repository
        Pathname to the corresponding directory in the source repository.

 CVS/Tag
        Contains the per-directory ``sticky'' tag or date information.
        This file is created/updated when you specify --rr or --DD to the
        cchheecckkoouutt or uuppddaattee commands, and no files are specified.

 CVS/Checkin.prog
        Name of program to run on `ccvvss ccoommmmiitt'.

 CVS/Update.prog
        Name of program to run on `ccvvss uuppddaattee'.

 _F_i_l_e_s _i_n _s_o_u_r_c_e _r_e_p_o_s_i_t_o_r_i_e_s_:

$CVSROOT/CVSROOT #

        Directory of global administrative files for repository.

 CVSROOT/commitinfo,v
        Records programs for filtering `ccvvss ccoommmmiitt' requests.

 CVSROOT/cvswrappers,v
        Records ccvvss wrapper commands to be used when checking files into
        and out of the repository.  Wrappers allow the file or directory
        to be processed on the way in and out of CVS.  The intended uses
        are many, one possible use would be to reformat a C file before
        the file is checked in, so all of the code in the repository looks
        the same.

 CVSROOT/editinfo,v
        Records programs for editing/validating `ccvvss ccoommmmiitt' log entries.

 CVSROOT/history
        Log file of ccvvss transactions.

 CVSROOT/loginfo,v
        Records programs for piping `ccvvss ccoommmmiitt' log entries.

 CVSROOT/modules,v
        Definitions for modules in this repository.

 CVSROOT/rcsinfo,v
        Records pathnames to templates used during a `ccvvss ccoommmmiitt'
        operation.

 CVSROOT/taginfo,v
        Records programs for validating/logging `ccvvss ttaagg' and `ccvvss rrttaagg'
        operations.

 MODULE/Attic
        Directory for removed source files.

 #cvs.lock
        A lock directory created by ccvvss when doing sensitive changes to
        the source repository.

 #cvs.tfl._p_i_d
        Temporary lock file for repository.

 #cvs.rfl._p_i_d
        A read lock.

 #cvs.wfl._p_i_d
        A write lock.

EENNVVIIRROONNMMEENNTT VVAARRIIAABBLLEESS #

CVSROOT #

        Should contain the full pathname to the root of the ccvvss source
        repository (where the RCS files are kept).  This information must
        be available to ccvvss for most commands to execute; if CVSROOT is
        not set, or if you wish to override it for one invocation, you can
        supply it on the command line: `ccvvss --dd _c_v_s_r_o_o_t _c_v_s___c_o_m_m_a_n_d......' You
        may not need to set CVSROOT if your ccvvss binary has the right path
        compiled in; use `ccvvss --vv' to display all compiled-in paths.

CVSREAD #

        If this is set, cchheecckkoouutt and uuppddaattee will try hard to make the
        files in your working directory read-only.  When this is not set,
        the default behavior is to permit modification of your working
        files.

 RCSBIN Specifies the full pathname where to find RCS programs, such as
        ccoo(11) and ccii(11) (CVS 1.9 and older).

CVSEDITOR #

        Specifies the program to use for recording log messages during
        ccoommmmiitt.  If not set, the VISUAL and EDITOR environment variables
        are tried (in that order).  If neither is set, a system-dependent
        default editor (e.g., vvii) is used.

CVSREADONLYFS #

        Setting this variable allows ccvvss to run properly without write
        access to its log file. This is especially useful when mounting a
        read-only source tree via NFS.

CVS_IGNORE_REMOTE_ROOT #

        If this variable is set then ccvvss will ignore all references to
        remote repositories in the CVS/Root file.

CVS_RSH #

        ccvvss uses the contents of this variable to determine the name of
        the remote shell command to use when starting a ccvvss server.  If
        this variable is not set then `sssshh' is used.

CVS_SERVER #

        ccvvss uses the contents of this variable to determine the name of
        the ccvvss server command.  If this variable is not set then `ccvvss' is
        used.

CVSWRAPPERS #

        This variable is used by the `ccvvsswwrraappppeerrss' script to determine the
        name of the wrapper file, in addition to the wrappers defaults
        contained in the repository (CVSROOT/cvswrappers) and the user's
        home directory (~/.cvswrappers).

AAUUTTHHOORRSS #

 Dick Grune
        Original author of the ccvvss shell script version posted to
        ccoommpp..ssoouurrcceess..uunniixx in the volume6 release of December, 1986.
        Credited with much of the ccvvss conflict resolution algorithms.

 Brian Berliner
        Coder and designer of the ccvvss program itself in April, 1989, based
        on the original work done by Dick.

 Jeff Polk
        Helped Brian with the design of the ccvvss module and vendor branch
        support and author of the cchheecckkiinn(11) shell script (the ancestor of
        `ccvvss iimmppoorrtt').

 And many others too numerous to mention here.

SSEEEE AALLSSOO #

 The most comprehensive manual for CVS is Version Management with CVS by
 Per Cederqvist et al.  Depending on your system, you may be able to get
 it with the iinnffoo ccvvss command or it may be available as cvs.ps
 (postscript), cvs.texinfo (texinfo source), or cvs.html.

 For CVS updates, more information on documentation, software related to
 CVS, development of CVS, and more, see:
           hhttttpp::////wwwwww..ccyycclliicc..ccoomm

 ccii(11), ccoo(11), ccvvss(55), ccvvssbbuugg(88), ddiiffff(11), ggrreepp(11), ppaattcchh(11), rrccss(11),
 rrccssddiiffff(11), rrccssmmeerrggee(11), rrlloogg(11).

CVS(1) #