   Copyright (C) 1992, 1993 Signum Support AB Copyright (C) 1993, 1994
Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the section entitled "GNU General Public License" is included
exactly as in the original, and provided that the entire resulting
derived work is distributed under the terms of a permission notice
identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the section entitled "GNU General Public License"
and this permission notice may be included in translations approved by
the Free Software Foundation instead of in the original English.

Setting up the files
====================

   The first step is to create the files inside the repository.  This
can be done in a couple of different ways.

Creating a directory tree from a number of files
------------------------------------------------

   When you begin using CVS, you will probably already have several
projects that can be put under CVS control.  In these cases the easiest
way is to use the `import' command.  An example is probably the easiest
way to explain how to use it.  If the files you want to install in CVS
reside in `WDIR', and you want them to appear in the repository as
`$CVSROOT/yoyodyne/RDIR', you can do this:

     $ cd WDIR
     $ cvs import -m "Imported sources" yoyodyne/RDIR yoyo start

   Unless you supply a log message with the `-m' flag, CVS starts an
editor and prompts for a message.  The string `yoyo' is a "vendor tag",
and `start' is a "release tag".  They may fill no purpose in this
context, but since CVS requires them they must be present.  See
Tracking sources, for more information about them.

   You can now verify that it worked, and remove your original source
directory.

     $ cd ..
     $ mv DIR DIR.orig
     $ cvs checkout yoyodyne/DIR       # Explanation below
     $ ls -R yoyodyne
     $ rm -r DIR.orig

Erasing the original sources is a good idea, to make sure that you do
not accidentally edit them in DIR, bypassing CVS.  Of course, it would
be wise to make sure that you have a backup of the sources before you
remove them.

   The `checkout' command can either take a module name as argument (as
it has done in all previous examples) or a path name relative to
`$CVSROOT', as it did in the example above.

   It is a good idea to check that the permissions CVS sets on the
directories inside `$CVSROOT' are reasonable, and that they belong to
the proper groups.  See File permissions.

   If some of the files you want to import are binary, you may want to
use the wrappers features to specify which files are binary and which
are not.  See Wrappers.

Creating Files From Other Version Control Systems
-------------------------------------------------

   If you have a project which you are maintaining with another version
control system, such as RCS, you may wish to put the files from that
project into CVS, and preserve the revision history of the files.

From RCS
     If you have been using RCS, find the RCS files--usually a file
     named `foo.c' will have its RCS file in `RCS/foo.c,v' (but it
     could be other places; consult the RCS documentation for details).
     Then create the appropriate directories in CVS if they do not
     already exist.  Then copy the files into the appropriate
     directories in the CVS repository (the name in the repository must
     be the name of the source file with `,v' added; the files go
     directly in the appopriate directory of the repository, not in an
     `RCS' subdirectory).  This is one of the few times when it is a
     good idea to access the CVS repository directly, rather than using
     CVS commands.  Then you are ready to check out a new working
     directory.

     The RCS file should not be locked when you move it into CVS; if it
     is, CVS will have trouble letting you operate on it.

From another version control system
     Many version control systems have the ability to export RCS files
     in the standard format.  If yours does, export the RCS files and
     then follow the above instructions.

From SCCS
     There is a script in the `contrib' directory of the CVS source
     distribution called `sccs2rcs' which converts SCCS files to RCS
     files.  Note: you must run it on a machine which has both SCCS and
     RCS installed, and like everything else in contrib it is
     unsupported (your mileage may vary).

Creating a directory tree from scratch
--------------------------------------

   For a new project, the easiest thing to do is probably to create an
empty directory structure, like this:

     $ mkdir tc
     $ mkdir tc/man
     $ mkdir tc/testing

   After that, you use the `import' command to create the corresponding
(empty) directory structure inside the repository:

     $ cd tc
     $ cvs import -m "Created directory structure" yoyodyne/DIR yoyo start

   Then, use `add' to add files (and new directories) as they appear.

   Check that the permissions CVS sets on the directories inside
`$CVSROOT' are reasonable.

Defining the module
===================

   The next step is to define the module in the `modules' file.  This
is not strictly necessary, but modules can be convenient in grouping
together related files and directories.

   In simple cases these steps are sufficient to define a module.

  1. Get a working copy of the modules file.

          $ cvs checkout CVSROOT/modules
          $ cd CVSROOT

  2. Edit the file and insert a line that defines the module.  See
     Intro administrative files, for an introduction.  See
     modules, for a full description of the modules file.  You can
     use the following line to define the module `tc':

          tc   yoyodyne/tc

  3. Commit your changes to the modules file.

          $ cvs commit -m "Added the tc module." modules

  4. Release the modules module.

          $ cd ..
          $ cvs release -d CVSROOT

Multiple developers
*******************

   When more than one person works on a software project things often
get complicated.  Often, two people try to edit the same file
simultaneously.  One solution, known as "file locking" or "reserved
checkouts", is to allow only one person to edit each file at a time.
This is the only solution with some version control systems, including
RCS and SCCS.  CVS doesn't have a very nice implementation of reserved
checkouts (yet) but there are ways to get it working (for example, see
the `cvs admin -l' command in admin options).  It also may be
possible to use the watches features described below, together with
suitable procedures (not enforced by software), to avoid having two
people edit at the same time.

   The default model with CVS is known as "unreserved checkouts".  In
this model, developers can edit their own "working copy" of a file
simultaneously.  The first person that commits his changes has no
automatic way of knowing that another has started to edit it.  Others
will get an error message when they try to commit the file.  They must
then use CVS commands to bring their working copy up to date with the
repository revision.  This process is almost automatic.

   CVS also supports mechanisms which facilitate various kinds of
communcation, without actually enforcing rules like reserved checkouts
do.

   The rest of this chapter describes how these various models work,
and some of the issues involved in choosing between them.

File status
===========

   Based on what operations you have performed on a checked out file,
and what operations others have performed to that file in the
repository, one can classify a file in a number of states.  The states,
as reported by the `status' command, are:

Up-to-date
     The file is identical with the latest revision in the repository
     for the branch in use.

Locally Modified
     You have edited the file, and not yet committed your changes.

Locally Added
     You have added the file with `add', and not yet committed your
     changes.

Locally Removed
     You have removed the file with `remove', and not yet committed
     your changes.

Needs Checkout
     Someone else has committed a newer revision to the repository.
     The name is slightly misleading; you will ordinarily use `update'
     rather than `checkout' to get that newer revision.

Needs Patch
     Like Needs Checkout, but the CVS server will send a patch rather
     than the entire file.  Sending a patch or sending an entire file
     accomplishes the same thing.

Needs Merge
     Someone else has committed a newer revision to the repository, and
     you have also made modifications to the file.

Unresolved Conflict
     This is like Locally Modified, except that a previous `update'
     command gave a conflict.  You need to resolve the conflict as
     described in Conflicts example.

Unknown
     CVS doesn't know anything about this file.  For example, you have
     created a new file and have not run `add'.

   To help clarify the file status, `status' also reports the `Working
revision' which is the revision that the file in the working directory
derives from, and the `Repository revision' which is the latest
revision in the repository for the branch in use.

   For information on the options to `status', see status.  For
information on its `Sticky tag' and `Sticky date' output, see
Sticky tags.  For information on its `Sticky options' output, see the
`-k' option in update options.

Bringing a file up to date
==========================

   When you want to update or merge a file, use the `update' command.
For files that are not up to date this is roughly equivalent to a
`checkout' command: the newest revision of the file is extracted from
the repository and put in your working copy of the module.

   Your modifications to a file are never lost when you use `update'.
If no newer revision exists, running `update' has no effect.  If you
have edited the file, and a newer revision is available, CVS will merge
all changes into your working copy.

   For instance, imagine that you checked out revision 1.4 and started
editing it.  In the meantime someone else committed revision 1.5, and
shortly after that revision 1.6.  If you run `update' on the file now,
CVS will incorporate all changes between revision 1.4 and 1.6 into your
file.

   If any of the changes between 1.4 and 1.6 were made too close to any
of the changes you have made, an "overlap" occurs.  In such cases a
warning is printed, and the resulting file includes both versions of
the lines that overlap, delimited by special markers.  See update,
for a complete description of the `update' command.

Conflicts example
=================

   Suppose revision 1.4 of `driver.c' contains this:

     #include <stdio.h>

     void main()
     {
         parse();
         if (nerr == 0)
             gencode();
         else
             fprintf(stderr, "No code generated.\n");
         exit(nerr == 0 ? 0 : 1);
     }

Revision 1.6 of `driver.c' contains this:

     #include <stdio.h>

     int main(int argc,
              char **argv)
     {
         parse();
         if (argc != 1)
         {
             fprintf(stderr, "tc: No args expected.\n");
             exit(1);
         }
         if (nerr == 0)
             gencode();
         else
             fprintf(stderr, "No code generated.\n");
         exit(!!nerr);
     }

Your working copy of `driver.c', based on revision 1.4, contains this
before you run `cvs update':

     #include <stdlib.h>
     #include <stdio.h>

     void main()
     {
         init_scanner();
         parse();
         if (nerr == 0)
             gencode();
         else
             fprintf(stderr, "No code generated.\n");
         exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
     }

You run `cvs update':

     $ cvs update driver.c
     RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
     retrieving revision 1.4
     retrieving revision 1.6
     Merging differences between 1.4 and 1.6 into driver.c
     rcsmerge warning: overlaps during merge
     cvs update: conflicts found in driver.c
     C driver.c

CVS tells you that there were some conflicts.  Your original working
file is saved unmodified in `.#driver.c.1.4'.  The new version of
`driver.c' contains this:

     #include <stdlib.h>
     #include <stdio.h>

     int main(int argc,
              char **argv)
     {
         init_scanner();
         parse();
         if (argc != 1)
         {
             fprintf(stderr, "tc: No args expected.\n");
             exit(1);
         }
         if (nerr == 0)
             gencode();
         else
             fprintf(stderr, "No code generated.\n");
     <<<<<<< driver.c
         exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
     =======
         exit(!!nerr);
     >>>>>>> 1.6
     }

Note how all non-overlapping modifications are incorporated in your
working copy, and that the overlapping section is clearly marked with
`<<<<<<<', `=======' and `>>>>>>>'.

   You resolve the conflict by editing the file, removing the markers
and the erroneous line.  Suppose you end up with this file:
     #include <stdlib.h>
     #include <stdio.h>

     int main(int argc,
              char **argv)
     {
         init_scanner();
         parse();
         if (argc != 1)
         {
             fprintf(stderr, "tc: No args expected.\n");
             exit(1);
         }
         if (nerr == 0)
             gencode();
         else
             fprintf(stderr, "No code generated.\n");
         exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
     }

You can now go ahead and commit this as revision 1.7.

     $ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
     Checking in driver.c;
     /usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c
     new revision: 1.7; previous revision: 1.6
     done

   For your protection, CVS will refuse to check in a file if a
conflict occurred and you have not resolved the conflict.  Currently to
resolve a conflict, you must change the timestamp on the file, and must
also insure that the file contains no conflict markers.  If your file
legitimately contains conflict markers (that is, occurrences of
`>>>>>>> ' at the start of a line that don't mark a conflict), then CVS
has trouble handling this and you need to start hacking on the
`CVS/Entries' file or other such workarounds.

   If you use release 1.04 or later of pcl-cvs (a GNU Emacs front-end
for CVS) you can use an Emacs package called emerge to help you resolve
conflicts.  See the documentation for pcl-cvs.

Informing others about commits
==============================

   It is often useful to inform others when you commit a new revision
of a file.  The `-i' option of the `modules' file, or the `loginfo'
file, can be used to automate this process.  See modules.  See
loginfo.  You can use these features of CVS to, for instance,
instruct CVS to mail a message to all developers, or post a message to
a local newsgroup.

Several developers simultaneously attempting to run CVS
=======================================================

   If several developers try to run CVS at the same time, one may get
the following message:

     [11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo

   CVS will try again every 30 seconds, and either continue with the
operation or print the message again, if it still needs to wait.  If a
lock seems to stick around for an undue amount of time, find the person
holding the lock and ask them about the cvs command they are running.
If they aren't running a cvs command, look for and remove files
starting with `#cvs.tfl', `#cvs.rfl', or `#cvs.wfl' from the repository.

   Note that these locks are to protect CVS's internal data structures
and have no relationship to the word "lock" in the sense used by
RCS--which refers to reserved checkouts (see Multiple developers.).

   Any number of people can be reading from a given repository at a
time; only when someone is writing do the locks prevent other people
from reading or writing.

   One might hope for the following property

     If someone commits some changes in one cvs command,
     then an update by someone else will either get all the
     changes, or none of them.

   but CVS does *not* have this property.  For example, given the files

     a/one.c
     a/two.c
     b/three.c
     b/four.c

   if someone runs

     cvs ci a/two.c b/three.c

   and someone else runs `cvs update' at the same time, the person
running `update' might get only the change to `b/three.c' and not the
change to `a/two.c'.

Mechanisms to track who is editing files
========================================

   For many groups, use of CVS in its default mode is perfectly
satisfactory.  Users may sometimes go to check in a modification only
to find that another modification has intervened, but they deal with it
and proceed with their check in.  Other groups prefer to be able to
know who is editing what files, so that if two people try to edit the
same file they can choose to talk about who is doing what when rather
than be surprised at check in time.  The features in this section allow
such coordination, while retaining the ability of two developers to
edit the same file at the same time.

   For maximum benefit developers should use `cvs edit' (not `chmod')
to make files read-write to edit them, and `cvs release' (not `rm') to
discard a working directory which is no longer in use, but CVS is not
able to enforce this behavior.

Telling CVS to watch certain files
----------------------------------

   To enable the watch features, you first specify that certain files
are to be watched.

 - Command: cvs watch on [`-l'] FILES ...
     Specify that developers should run `cvs edit' before editing
     FILES.  CVS will create working copies of FILES read-only, to
     remind developers to run the `cvs edit' command before working on
     them.

     If FILES includes the name of a directory, CVS arranges to watch
     all files added to the corresponding repository directory, and
     sets a default for files added in the future; this allows the user
     to set notification policies on a per-directory basis.  The
     contents of the directory are processed recursively, unless the
     `-l' option is given.

     If FILES is omitted, it defaults to the current directory.

 - Command: cvs watch off [`-l'] FILES ...
     Do not provide notification about work on FILES.  CVS will create
     working copies of FILES read-write.

     The FILES and `-l' arguments are processed as for `cvs watch on'.

Telling CVS to notify you
-------------------------

   You can tell CVS that you want to receive notifications about
various actions taken on a file.  You can do this without using `cvs
watch on' for the file, but generally you will want to use `cvs watch
on', so that developers use the `cvs edit' command.

 - Command: cvs watch add [`-a' ACTION] [`-l'] FILES ...
     Add the current user to the list of people to receive notification
     of work done on FILES.

     The `-a' option specifies what kinds of events CVS should notify
     the user about.  ACTION is one of the following:

    `edit'
          Another user has applied the `cvs edit' command (described
          below) to a file.

    `unedit'
          Another user has applied the `cvs unedit' command (described
          below) or the `cvs release' command to a file, or has deleted
          the file and allowed `cvs update' to recreate it.

    `commit'
          Another user has committed changes to a file.

    `all'
          All of the above.

    `none'
          None of the above.  (This is useful with `cvs edit',
          described below.)

     The `-a' option may appear more than once, or not at all.  If
     omitted, the action defaults to `all'.

     The FILES and `-l' option are processed as for the `cvs watch'
     commands.

 - Command: cvs watch remove [`-a' ACTION] [`-l'] FILES ...
     Remove a notification request established using `cvs watch add';
     the arguments are the same.  If the `-a' option is present, only
     watches for the specified actions are removed.

   When the conditions exist for notification, CVS calls the `notify'
administrative file.  Edit `notify' as one edits the other
administrative files (see Intro administrative files.).  This file
follows the usual conventions for administrative files (see
syntax.), where each line is a regular expression followed by a
command to execute.  The command should contain a single ocurrence of
`%s' which will be replaced by the user to notify; the rest of the
information regarding the notification will be supplied to the command
on standard input.  The standard thing to put in the `notify' file is
the single line:

     ALL mail %s -s \"CVS notification\"

   This causes users to be notified by electronic mail.

   Note that if you set this up in the straightforward way, users
receive notifications on the server machine.  One could of course write
a `notify' script which directed notifications elsewhere, but to make
this easy, CVS allows you to associate a notification address for each
user.  To do so create a file `users' in `CVSROOT' with a line for each
user in the format USER:VALUE.  Then instead of passing the name of the
user to be notified to `notify', CVS will pass the VALUE (normally an
email address on some other machine).

How to edit a file which is being watched
-----------------------------------------

   Since a file which is being watched is checked out read-only, you
cannot simply edit it.  To make it read-write, and inform others that
you are planning to edit it, use the `cvs edit' command.  Some systems
call this a "checkout", but CVS uses that term for obtaining a copy of
the sources (see Getting the source.), an operation which those
systems call a "get" or a "fetch".

 - Command: cvs edit [OPTIONS] FILES ...
     Prepare to edit the working files FILES.  CVS makes the FILES
     read-write, and notifies users who have requested `edit'
     notification for any of FILES.

     The `cvs edit' command accepts the same OPTIONS as the `cvs watch
     add' command, and establishes a temporary watch for the user on
     FILES; CVS will remove the watch when FILES are `unedit'ed or
     `commit'ted.  If the user does not wish to receive notifications,
     she should specify `-a none'.

     The FILES and `-l' option are processed as for the `cvs watch'
     commands.

   Normally when you are done with a set of changes, you use the `cvs
commit' command, which checks in your changes and returns the watched
files to their usual read-only state.  But if you instead decide to
abandon your changes, or not to make any changes, you can use the `cvs
unedit' command.

 - Command: cvs unedit [`-l'] FILES ...
     Abandon work on the working files FILES, and revert them to the
     repository versions on which they are based.  CVS makes those
     FILES read-only for which users have requested notification using
     `cvs watch on'.  CVS notifies users who have requested `unedit'
     notification for any of FILES.

     The FILES and `-l' option are processed as for the `cvs watch'
     commands.

     If watches are not in use, the `unedit' command probably does not
     work, and the way to revert to the repository version is to remove
     the file and then use `cvs update' to get a new copy.  The meaning
     is not precisely the same; removing and updating may also bring in
     some changes which have been made in the repository since the last
     time you updated.

   When using client/server CVS, you can use the `cvs edit' and `cvs
unedit' commands even if CVS is unable to succesfully communicate with
the server; the notifications will be sent upon the next successful CVS
command.

Information about who is watching and editing
---------------------------------------------

 - Command: cvs watchers [`-l'] FILES ...
     List the users currently watching changes to FILES.  The report
     includes the files being watched, and the mail address of each
     watcher.

     The FILES and `-l' arguments are processed as for the `cvs watch'
     commands.

 - Command: cvs editors [`-l'] FILES ...
     List the users currently working on FILES.  The report includes
     the mail address of each user, the time when the user began
     working with the file, and the host and path of the working
     directory containing the file.

     The FILES and `-l' arguments are processed as for the `cvs watch'
     commands.

Using watches with old versions of CVS
--------------------------------------

   If you use the watch features on a repository, it creates `CVS'
directories in the repository and stores the information about watches
in that directory.  If you attempt to use CVS 1.6 or earlier with the
repository, you get an error message such as

     cvs update: cannot open CVS/Entries for reading: No such file or directory

   and your operation will likely be aborted.  To use the watch
features, you must upgrade all copies of CVS which use that repository
in local or server mode.  If you cannot upgrade, use the `watch off' and
`watch remove' commands to remove all watches, and that will restore
the repository to a state which CVS 1.6 can cope with.

Choosing between reserved or unreserved checkouts
=================================================

   Reserved and unreserved checkouts each have pros and cons.  Let it
be said that a lot of this is a matter of opinion or what works given
different groups' working styles, but here is an attempt to briefly
describe the issues.  There are many ways to organize a team of
developers.  CVS does not try to enforce a certain organization.  It is
a tool that can be used in several ways.

   Reserved checkouts can be very counter-productive.  If two persons
want to edit different parts of a file, there may be no reason to
prevent either of them from doing so.  Also, it is common for someone
to take out a lock on a file, because they are planning to edit it, but
then forget to release the lock.

   People, especially people who are familiar with reserved checkouts,
often wonder how often conflicts occur if unreserved checkouts are
used, and how difficult they are to resolve.  The experience with many
groups is that they occur rarely and usually are relatively
straightforward to resolve.

   The rarity of serious conflicts may be surprising, until one realizes
that they occur only when two developers disagree on the proper design
for a given section of code; such a disagreement suggests that the team
has not been communicating properly in the first place.  In order to
collaborate under *any* source management regimen, developers must
agree on the general design of the system; given this agreement,
overlapping changes are usually straightforward to merge.

   In some cases unreserved checkouts are clearly inappropriate.  If no
merge tool exists for the kind of file you are managing (for example
word processor files or files edited by Computer Aided Design
programs), and it is not desirable to change to a program which uses a
mergeable data format, then resolving conflicts is going to be
unpleasant enough that you generally will be better off to simply avoid
the conflicts instead, by using reserved checkouts.

   The watches features described above in Watches can be
considered to be an intermediate model between reserved checkouts and
unreserved checkouts.  When you go to edit a file, it is possible to
find out who else is editing it.  And rather than having the system
simply forbid both people editing the file, it can tell you what the
situation is and let you figure out whether it is a problem in that
particular case or not.  Therefore, for some groups it can be
considered the best of both the reserved checkout and unreserved
checkout worlds.

Branches
********

   So far, all revisions shown in this manual have been on the "main
trunk" of the revision tree, i.e., all revision numbers have been of
the form X.Y.  One useful feature, especially when maintaining several
releases of a software product at once, is the ability to make branches
on the revision tree.  "Tags", symbolic names for revisions, will also
be introduced in this chapter.

Tags-Symbolic revisions
=======================

   The revision numbers live a life of their own.  They need not have
anything at all to do with the release numbers of your software
product.  Depending on how you use CVS the revision numbers might
change several times between two releases.  As an example, some of the
source files that make up RCS 5.6 have the following revision numbers:

     ci.c            5.21
     co.c            5.9
     ident.c         5.3
     rcs.c           5.12
     rcsbase.h       5.11
     rcsdiff.c       5.10
     rcsedit.c       5.11
     rcsfcmp.c       5.9
     rcsgen.c        5.10
     rcslex.c        5.11
     rcsmap.c        5.2
     rcsutil.c       5.10

   You can use the `tag' command to give a symbolic name to a certain
revision of a file.  You can use the `-v' flag to the `status' command
to see all tags that a file has, and which revision numbers they
represent.  Tag names can contain uppercase and lowercase letters,
digits, `-', and `_'.  The two tag names `BASE' and `HEAD' are reserved
for use by CVS.  It is expected that future names which are special to
CVS will contain characters such as `%' or `=', rather than being named
analogously to `BASE' and `HEAD', to avoid conflicts with actual tag
names.

   The following example shows how you can add a tag to a file.  The
commands must be issued inside your working copy of the module.  That
is, you should issue the command in the directory where `backend.c'
resides.

     $ cvs tag release-0-4 backend.c
     T backend.c
     $ cvs status -v backend.c
     ===================================================================
     File: backend.c         Status: Up-to-date

         Version:            1.4     Tue Dec  1 14:39:01 1992
         RCS Version:        1.4     /usr/local/cvsroot/yoyodyne/tc/backend.c,v
         Sticky Tag:         (none)
         Sticky Date:        (none)
         Sticky Options:     (none)

         Existing Tags:
             release-0-4                     (revision: 1.4)

   There is seldom reason to tag a file in isolation.  A more common
use is to tag all the files that constitute a module with the same tag
at strategic points in the development life-cycle, such as when a
release is made.

     $ cvs tag release-1-0 .
     cvs tag: Tagging .
     T Makefile
     T backend.c
     T driver.c
     T frontend.c
     T parser.c

   (When you give CVS a directory as argument, it generally applies the
operation to all the files in that directory, and (recursively), to any
subdirectories that it may contain.  See Recursive behavior.)

   The `checkout' command has a flag, `-r', that lets you check out a
certain revision of a module.  This flag makes it easy to retrieve the
sources that make up release 1.0 of the module `tc' at any time in the
future:

     $ cvs checkout -r release-1-0 tc

This is useful, for instance, if someone claims that there is a bug in
that release, but you cannot find the bug in the current working copy.

   You can also check out a module as it was at any given date.  See
checkout options.

   When you tag more than one file with the same tag you can think
about the tag as "a curve drawn through a matrix of filename vs.
revision number."  Say we have 5 files with the following revisions:

             file1   file2   file3   file4   file5

             1.1     1.1     1.1     1.1  /--1.1*      <-*-  TAG
             1.2*-   1.2     1.2    -1.2*-
             1.3  \- 1.3*-   1.3   / 1.3
             1.4          \  1.4  /  1.4
                           \-1.5*-   1.5
                             1.6

   At some time in the past, the `*' versions were tagged.  You can
think of the tag as a handle attached to the curve drawn through the
tagged revisions.  When you pull on the handle, you get all the tagged
revisions.  Another way to look at it is that you "sight" through a set
of revisions that is "flat" along the tagged revisions, like this:

             file1   file2   file3   file4   file5

                             1.1
                             1.2
                     1.1     1.3                       _
             1.1     1.2     1.4     1.1              /
             1.2*----1.3*----1.5*----1.2*----1.1     (--- <--- Look here
             1.3             1.6     1.3              \_
             1.4                     1.4
                                     1.5

What branches are good for
==========================

   Suppose that release 1.0 of tc has been made.  You are continuing to
develop tc, planning to create release 1.1 in a couple of months.
After a while your customers start to complain about a fatal bug.  You
check out release 1.0 (see Tags.) and find the bug (which turns out
to have a trivial fix).  However, the current revision of the sources
are in a state of flux and are not expected to be stable for at least
another month.  There is no way to make a bugfix release based on the
newest sources.

   The thing to do in a situation like this is to create a "branch" on
the revision trees for all the files that make up release 1.0 of tc.
You can then make modifications to the branch without disturbing the
main trunk.  When the modifications are finished you can select to
either incorporate them on the main trunk, or leave them on the branch.

Creating a branch
=================

   The `rtag' command can be used to create a branch.  The `rtag'
command is much like `tag', but it does not require that you have a
working copy of the module.  See rtag.  (You can also use the `tag'
command; see tag.).

     $ cvs rtag -b -r release-1-0 release-1-0-patches tc

   The `-b' flag makes `rtag' create a branch (rather than just a
symbolic revision name).  `-r release-1-0' says that this branch should
be rooted at the node (in the revision tree) that corresponds to the tag
`release-1-0'.  Note that the numeric revision number that matches
`release-1-0' will probably be different from file to file.  The name
of the new branch is `release-1-0-patches', and the module affected is
`tc'.

   To fix the problem in release 1.0, you need a working copy of the
branch you just created.

     $ cvs checkout -r release-1-0-patches tc
     $ cvs status -v driver.c backend.c
     ===================================================================
     File: driver.c          Status: Up-to-date

         Version:            1.7     Sat Dec  5 18:25:54 1992
         RCS Version:        1.7     /usr/local/cvsroot/yoyodyne/tc/driver.c,v
         Sticky Tag:         release-1-0-patches (branch: 1.7.2)
         Sticky Date:        (none)
         Sticky Options:     (none)

         Existing Tags:
             release-1-0-patches             (branch: 1.7.2)
             release-1-0                     (revision: 1.7)

     ===================================================================
     File: backend.c         Status: Up-to-date

         Version:            1.4     Tue Dec  1 14:39:01 1992
         RCS Version:        1.4     /usr/local/cvsroot/yoyodyne/tc/backend.c,v
         Sticky Tag:         release-1-0-patches (branch: 1.4.2)
         Sticky Date:        (none)
         Sticky Options:     (none)

         Existing Tags:
             release-1-0-patches             (branch: 1.4.2)
             release-1-0                     (revision: 1.4)
             release-0-4                     (revision: 1.4)

   As the output from the `status' command shows the branch number is
created by adding a digit at the tail of the revision number it is
based on.  (If `release-1-0' corresponds to revision 1.4, the branch's
revision number will be 1.4.2.  For obscure reasons CVS always gives
branches even numbers, starting at 2.  See Revision numbers).

Sticky tags
===========

   The `-r release-1-0-patches' flag that was given to `checkout' in
the previous example is "sticky", that is, it will apply to subsequent
commands in this directory.  If you commit any modifications, they are
committed on the branch.  You can later merge the modifications into
the main trunk.  See Merging.

   You can use the `status' command to see what sticky tags or dates
are set:

     $ vi driver.c   # Fix the bugs
     $ cvs commit -m "Fixed initialization bug" driver.c
     Checking in driver.c;
     /usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c
     new revision: 1.7.2.1; previous revision: 1.7
     done
     $ cvs status -v driver.c
     ===================================================================
     File: driver.c          Status: Up-to-date

         Version:            1.7.2.1 Sat Dec  5 19:35:03 1992
         RCS Version:        1.7.2.1 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
         Sticky Tag:         release-1-0-patches (branch: 1.7.2)
         Sticky Date:        (none)
         Sticky Options:     (none)

         Existing Tags:
             release-1-0-patches             (branch: 1.7.2)
             release-1-0                     (revision: 1.7)

   The sticky tags will remain on your working files until you delete
them with `cvs update -A'.  The `-A' option retrieves the version of
the file from the head of the trunk, and forgets any sticky tags,
dates, or options.

   Sticky tags are not just for branches.  For example, suppose that
you want to avoid updating your working directory, to isolate yourself
from possibly destabilizing changes other people are making.  You can,
of course, just refrain from running `cvs update'.  But if you want to
avoid updating only a portion of a larger tree, then sticky tags can
help.  If you check out a certain revision (such as 1.4) it will become
sticky.  Subsequent `cvs update' will not retrieve the latest revision
until you reset the tag with `cvs update -A'.  Likewise, use of the
`-D' option to `update' or `checkout' sets a "sticky date", which,
similarly, causes that date to be used for future retrievals.

   Many times you will want to retrieve an old version of a file
without setting a sticky tag.  The way to do that is with the `-p'
option to `checkout' or `update', which sends the contents of the file
to standard output.  For example, suppose you have a file named `file1'
which existed as revision 1.1, and you then removed it (thus adding a
dead revision 1.2).  Now suppose you want to add it again, with the same
contents it had previously.  Here is how to do it:

     $ cvs update -p -r 1.1 file1 >file1
     ===================================================================
     Checking out file1
     RCS:  /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
     VERS: 1.1
     ***************
     $ cvs add file1
     cvs add: re-adding file file1 (in place of dead revision 1.2)
     cvs add: use 'cvs commit' to add this file permanently
     $ cvs commit -m test
     Checking in file1;
     /tmp/cvs-sanity/cvsroot/first-dir/file1,v  <--  file1
     new revision: 1.3; previous revision: 1.2
     done
     $

Merging
*******

   You can include the changes made between any two revisions into your
working copy, by "merging".  You can then commit that revision, and
thus effectively copy the changes onto another branch.

Merging an entire branch
========================

   You can merge changes made on a branch into your working copy by
giving the `-j BRANCH' flag to the `update' command.  With one `-j
BRANCH' option it merges the changes made between the point where the
branch forked and newest revision on that branch (into your working
copy).

   The `-j' stands for "join".

   Consider this revision tree:

     +-----+    +-----+    +-----+    +-----+
     ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
     +-----+    +-----+    +-----+    +-----+
                     !
                     !
                     !   +---------+    +---------+
     Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
                         +---------+    +---------+

The branch 1.2.2 has been given the tag (symbolic name) `R1fix'.  The
following example assumes that the module `mod' contains only one file,
`m.c'.

     $ cvs checkout mod               # Retrieve the latest revision, 1.4

     $ cvs update -j R1fix m.c        # Merge all changes made on the branch,
                                      # i.e. the changes between revision 1.2
                                      # and 1.2.2.2, into your working copy
                                      # of the file.

     $ cvs commit -m "Included R1fix" # Create revision 1.5.

   A conflict can result from a merge operation.  If that happens, you
should resolve it before committing the new revision.  See Conflicts example.

   The `checkout' command also supports the `-j BRANCH' flag.  The same
effect as above could be achieved with this:

     $ cvs checkout -j R1fix mod
     $ cvs commit -m "Included R1fix"

Merging from a branch several times
===================================

   Continuing our example, the revision tree now looks like this:

     +-----+    +-----+    +-----+    +-----+    +-----+
     ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !      <- The main trunk
     +-----+    +-----+    +-----+    +-----+    +-----+
                     !                           *
                     !                          *
                     !   +---------+    +---------+
     Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
                         +---------+    +---------+

   where the starred line represents the merge from the `R1fix' branch
to the main trunk, as just discussed.

   Now suppose that development continues on the `R1fix' branch:

     +-----+    +-----+    +-----+    +-----+    +-----+
     ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !      <- The main trunk
     +-----+    +-----+    +-----+    +-----+    +-----+
                     !                           *
                     !                          *
                     !   +---------+    +---------+    +---------+
     Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
                         +---------+    +---------+    +---------+

   and then you want to merge those new changes onto the main trunk.
If you just use the `cvs update -j R1fix m.c' command again, CVS will
attempt to merge again the changes which you have already merged, which
can have undesirable side effects.

   So instead you need to specify that you only want to merge the
changes on the branch which have not yet been merged into the trunk.
To do that you specify two `-j' options, and CVS merges the changes from
the first revision to the second revision.  For example, in this case
the simplest way would be

     cvs update -j 1.2.2.2 -j R1fix m.c    # Merge changes from 1.2.2.2 to the
                                           # head of the R1fix branch

   The problem with this is that you need to specify the 1.2.2.2
revision manually.  A slightly better approach might be to use the date
the last merge was done:

     cvs update -j R1fix:yesterday -j R1fix m.c

   Better yet, tag the R1fix branch after every merge into the trunk,
and then use that tag for subsequent merges:

     cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c

Merging differences between any two revisions
=============================================

   With two `-j REVISION' flags, the `update' (and `checkout') command
can merge the differences between any two revisions into your working
file.

     $ cvs update -j 1.5 -j 1.3 backend.c

will *remove* all changes made between revision 1.3 and 1.5.  Note the
order of the revisions!

   If you try to use this option when operating on multiple files,
remember that the numeric revisions will probably be very different
between the various files that make up a module.  You almost always use
symbolic tags rather than revision numbers when operating on multiple
files.

Merging can add or remove files
===============================

   If the changes which you are merging involve removing or adding some
files, `update -j' will reflect such additions or removals.

   For example:
     cvs update -A
     touch a b c
     cvs add a b c ; cvs ci -m "added" a b c
     cvs tag -b branchtag
     cvs update -r branchtag
     touch d ; cvs add d
     rm a ; cvs rm a
     cvs ci -m "added d, removed a"
     cvs update -A
     cvs update -jbranchtag