path: root/gnu/usr.bin/cvs/doc/cvs.info-4

This is cvs.info, produced by makeinfo version 4.0 from cvs.texinfo.

START-INFO-DIR-ENTRY
* CVS: (cvs).          Concurrent Versions System
END-INFO-DIR-ENTRY

   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 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 this permission notice may be stated in a
translation approved by the Free Software Foundation.


File: cvs.info,  Node: Moving directories,  Prev: Moving files,  Up: Adding and removing

Moving and renaming directories
===============================

   The normal way to rename or move a directory is to rename or move
each file within it as described in *Note Outside::.  Then check out
with the `-P' option, as described in *Note Removing directories::.

   If you really want to hack the repository to rename or delete a
directory in the repository, you can do it like this:

  1. Inform everyone who has a checked out copy of the directory that
     the directory will be renamed.  They should commit all their
     changes, and remove their working copies, before you take the
     steps below.

  2. Rename the directory inside the repository.

          $ cd $CVSROOT/PARENT-DIR
          $ mv OLD-DIR NEW-DIR

  3. Fix the CVS administrative files, if necessary (for instance if
     you renamed an entire module).

  4. Tell everyone that they can check out again and continue working.


   If someone had a working copy the CVS commands will cease to work
for him, until he removes the directory that disappeared inside the
repository.

   It is almost always better to move the files in the directory
instead of moving the directory.  If you move the directory you are
unlikely to be able to retrieve old releases correctly, since they
probably depend on the name of the directories.


File: cvs.info,  Node: History browsing,  Next: Binary files,  Prev: Adding and removing,  Up: Top

History browsing
****************

   Once you have used CVS to store a version control history--what
files have changed when, how, and by whom, there are a variety of
mechanisms for looking through the history.

* Menu:

* log messages::                Log messages
* history database::            The history database
* user-defined logging::        User-defined logging
* annotate::                    What revision modified each line of a file?


File: cvs.info,  Node: log messages,  Next: history database,  Up: History browsing

Log messages
============

   Whenever you commit a file you specify a log message.

   To look through the log messages which have been specified for every
revision which has been committed, use the `cvs log' command (*note
log::).


File: cvs.info,  Node: history database,  Next: user-defined logging,  Prev: log messages,  Up: History browsing

The history database
====================

   You can use the history file (*note history file::) to log various
CVS actions.  To retrieve the information from the history file, use
the `cvs history' command (*note history::).

   Note: you can control what is logged to this file by using the
`LogHistory' keyword in the `CVSROOT/config' file (*note config::).


File: cvs.info,  Node: user-defined logging,  Next: annotate,  Prev: history database,  Up: History browsing

User-defined logging
====================

   You can customize CVS to log various kinds of actions, in whatever
manner you choose.  These mechanisms operate by executing a script at
various times.  The script might append a message to a file listing the
information and the programmer who created it, or send mail to a group
of developers, or, perhaps, post a message to a particular newsgroup.
To log commits, use the `loginfo' file (*note loginfo::).  To log
commits, checkouts, exports, and tags, respectively, you can also use
the `-i', `-o', `-e', and `-t' options in the modules file.  For a more
flexible way of giving notifications to various users, which requires
less in the way of keeping centralized scripts up to date, use the `cvs
watch add' command (*note Getting Notified::); this command is useful
even if you are not using `cvs watch on'.

   The `taginfo' file defines programs to execute when someone executes
a `tag' or `rtag' command.  The `taginfo' file has the standard form
for administrative files (*note Administrative files::), where each
line is a regular expression followed by a command to execute.  The
arguments passed to the command are, in order, the TAGNAME, OPERATION
(`add' for `tag', `mov' for `tag -F', and `del' for `tag -d'),
REPOSITORY, and any remaining are pairs of FILENAME REVISION.  A
non-zero exit of the filter program will cause the tag to be aborted.

   Here is an example of using taginfo to log tag and rtag commands.
In the taginfo file put:

     ALL /usr/local/cvsroot/CVSROOT/loggit

   Where `/usr/local/cvsroot/CVSROOT/loggit' contains the following
script:

     #!/bin/sh
     echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog


File: cvs.info,  Node: annotate,  Prev: user-defined logging,  Up: History browsing

Annotate command
================

 - Command: cvs annotate [`-flR'] [`-r rev'|`-D date'] files ...
     For each file in FILES, print the head revision of the trunk,
     together with information on the last modification for each line.
     For example:

          $ cvs annotate ssfile
          Annotations for ssfile
          ***************
          1.1          (mary     27-Mar-96): ssfile line 1
          1.2          (joe      28-Mar-96): ssfile line 2

     The file `ssfile' currently contains two lines.  The `ssfile line
     1' line was checked in by `mary' on March 27.  Then, on March 28,
     `joe' added a line `ssfile line 2', without modifying the `ssfile
     line 1' line.  This report doesn't tell you anything about lines
     which have been deleted or replaced; you need to use `cvs diff'
     for that (*note diff::).


   The options to `cvs annotate' are listed in *Note Invoking CVS::,
and can be used to select the files and revisions to annotate.  The
options are described in more detail in *Note Common options::.


File: cvs.info,  Node: Binary files,  Next: Multiple developers,  Prev: History browsing,  Up: Top

Handling binary files
*********************

   The most common use for CVS is to store text files.  With text
files, CVS can merge revisions, display the differences between
revisions in a human-visible fashion, and other such operations.
However, if you are willing to give up a few of these abilities, CVS
can store binary files.  For example, one might store a web site in CVS
including both text files and binary images.

* Menu:

* Binary why::     More details on issues with binary files
* Binary howto::   How to store them


File: cvs.info,  Node: Binary why,  Next: Binary howto,  Up: Binary files

The issues with binary files
============================

   While the need to manage binary files may seem obvious if the files
that you customarily work with are binary, putting them into version
control does present some additional issues.

   One basic function of version control is to show the differences
between two revisions.  For example, if someone else checked in a new
version of a file, you may wish to look at what they changed and
determine whether their changes are good.  For text files, CVS provides
this functionality via the `cvs diff' command.  For binary files, it
may be possible to extract the two revisions and then compare them with
a tool external to CVS (for example, word processing software often has
such a feature).  If there is no such tool, one must track changes via
other mechanisms, such as urging people to write good log messages, and
hoping that the changes they actually made were the changes that they
intended to make.

   Another ability of a version control system is the ability to merge
two revisions.  For CVS this happens in two contexts.  The first is
when users make changes in separate working directories (*note Multiple
developers::).  The second is when one merges explicitly with the
`update -j' command (*note Branching and merging::).

   In the case of text files, CVS can merge changes made independently,
and signal a conflict if the changes conflict.  With binary files, the
best that CVS can do is present the two different copies of the file,
and leave it to the user to resolve the conflict.  The user may choose
one copy or the other, or may run an external merge tool which knows
about that particular file format, if one exists.  Note that having the
user merge relies primarily on the user to not accidentally omit some
changes, and thus is potentially error prone.

   If this process is thought to be undesirable, the best choice may be
to avoid merging.  To avoid the merges that result from separate
working directories, see the discussion of reserved checkouts (file
locking) in *Note Multiple developers::.  To avoid the merges resulting
from branches, restrict use of branches.


File: cvs.info,  Node: Binary howto,  Prev: Binary why,  Up: Binary files

How to store binary files
=========================

   There are two issues with using CVS to store binary files.  The
first is that CVS by default converts line endings between the
canonical form in which they are stored in the repository (linefeed
only), and the form appropriate to the operating system in use on the
client (for example, carriage return followed by line feed for Windows
NT).

   The second is that a binary file might happen to contain data which
looks like a keyword (*note Keyword substitution::), so keyword
expansion must be turned off.

   The `-kb' option available with some CVS commands insures that
neither line ending conversion nor keyword expansion will be done.

   Here is an example of how you can create a new file using the `-kb'
flag:

     $ echo '$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $' > kotest
     $ cvs add -kb -m"A test file" kotest
     $ cvs ci -m"First checkin; contains a keyword" kotest

   If a file accidentally gets added without `-kb', one can use the
`cvs admin' command to recover.  For example:

     $ echo '$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $' > kotest
     $ cvs add -m"A test file" kotest
     $ cvs ci -m"First checkin; contains a keyword" kotest
     $ cvs admin -kb kotest
     $ cvs update -A kotest
     # For non-unix systems:
     # Copy in a good copy of the file from outside CVS
     $ cvs commit -m "make it binary" kotest

   When you check in the file `kotest' the file is not preserved as a
binary file, because you did not check it in as a binary file.  The `cvs
admin -kb' command sets the default keyword substitution method for
this file, but it does not alter the working copy of the file that you
have.  If you need to cope with line endings (that is, you are using
CVS on a non-unix system), then you need to check in a new copy of the
file, as shown by the `cvs commit' command above.  On unix, the `cvs
update -A' command suffices.

   However, in using `cvs admin -k' to change the keyword expansion, be
aware that the keyword expansion mode is not version controlled.  This
means that, for example, that if you have a text file in old releases,
and a binary file with the same name in new releases, CVS provides no
way to check out the file in text or binary mode depending on what
version you are checking out.  There is no good workaround for this
problem.

   You can also set a default for whether `cvs add' and `cvs import'
treat a file as binary based on its name; for example you could say
that files who names end in `.exe' are binary.  *Note Wrappers::.
There is currently no way to have CVS detect whether a file is binary
based on its contents.  The main difficulty with designing such a
feature is that it is not clear how to distinguish between binary and
non-binary files, and the rules to apply would vary considerably with
the operating system.


File: cvs.info,  Node: Multiple developers,  Next: Revision management,  Prev: Binary files,  Up: Top

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.  Currently the usual way to get reserved checkouts with
CVS is the `cvs admin -l' command (*note admin options::).  This is not
as nicely integrated into CVS as the watch features, described below,
but it seems that most people with a need for reserved checkouts find
it adequate.  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
communication, 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.

* Menu:

* File status::                 A file can be in several states
* Updating a file::             Bringing a file up-to-date
* Conflicts example::           An informative example
* Informing others::            To cooperate you must inform
* Concurrency::                 Simultaneous repository access
* Watches::                     Mechanisms to track who is editing files
* Choosing a model::            Reserved or unreserved checkouts?


File: cvs.info,  Node: File status,  Next: Updating a file,  Up: Multiple developers

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.

File had conflicts on merge
     This is like Locally Modified, except that a previous `update'
     command gave a conflict.  If you have not already done so, you
     need to resolve the conflict as described in *Note 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.

   The options to `status' are listed in *Note Invoking CVS::.  For
information on its `Sticky tag' and `Sticky date' output, see *Note
Sticky tags::.  For information on its `Sticky options' output, see the
`-k' option in *Note update options::.

   You can think of the `status' and `update' commands as somewhat
complementary.  You use `update' to bring your files up to date, and you
can use `status' to give you some idea of what an `update' would do (of
course, the state of the repository might change before you actually run
`update').  In fact, if you want a command to display file status in a
more brief format than is displayed by the `status' command, you can
invoke

     $ cvs -n -q update

   The `-n' option means to not actually do the update, but merely to
display statuses; the `-q' option avoids printing the name of each
directory.  For more information on the `update' command, and these
options, see *Note Invoking CVS::.


File: cvs.info,  Node: Updating a file,  Next: Conflicts example,  Prev: File status,  Up: Multiple developers

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 directory.

   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.  *Note update::,
for a complete description of the `update' command.


File: cvs.info,  Node: Conflicts example,  Next: Informing others,  Prev: Updating a file,  Up: Multiple developers

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.  In
previous versions of CVS, you also needed to insure that the file
contains no conflict markers.  Because your file may legitimately
contain conflict markers (that is, occurrences of `>>>>>>> ' at the
start of a line that don't mark a conflict), the current version of CVS
will print a warning and proceed to check in the file.

   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.


File: cvs.info,  Node: Informing others,  Next: Concurrency,  Prev: Conflicts example,  Up: Multiple developers

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.  *Note modules::.  *Note
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.


File: cvs.info,  Node: Concurrency,  Next: Watches,  Prev: Informing others,  Up: Multiple developers

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 in the repository directory
mentioned in the message and remove files which they own whose names
start with `#cvs.rfl', `#cvs.wfl', or `#cvs.lock'.

   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 (*note 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'.


File: cvs.info,  Node: Watches,  Next: Choosing a model,  Prev: Concurrency,  Up: Multiple developers

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.

* Menu:

* Setting a watch::             Telling CVS to watch certain files
* Getting Notified::            Telling CVS to notify you
* Editing files::               How to edit a file which is being watched
* Watch information::           Information about who is watching and editing
* Watches Compatibility::       Watches interact poorly with CVS 1.6 or earlier


File: cvs.info,  Node: Setting a watch,  Next: Getting Notified,  Up: Watches

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 [`-lR'] 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.  The `-R' option can be used to force
     recursion if the `-l' option is set in `~/.cvsrc' (*note
     ~/.cvsrc::).

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


 - Command: cvs watch off [`-lR'] files ...
     Do not create FILES read-only on checkout; thus, developers will
     not be reminded to use `cvs edit' and `cvs unedit'.

     The FILES and options are processed as for `cvs watch on'.



File: cvs.info,  Node: Getting Notified,  Next: Editing files,  Prev: Setting a watch,  Up: Watches

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] [`-lR'] 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 options are processed as for the `cvs watch'
     commands.


 - Command: cvs watch remove [`-a' action] [`-lR'] 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 (*note Intro administrative files::).  This file
follows the usual conventions for administrative files (*note
syntax::), where each line is a regular expression followed by a
command to execute.  The command should contain a single occurrence 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).

   CVS does not notify you for your own changes.  Currently this check
is done based on whether the user name of the person taking the action
which triggers notification matches the user name of the person getting
notification.  In fact, in general, the watches features only track one
edit by each user.  It probably would be more useful if watches tracked
each working directory separately, so this behavior might be worth
changing.


File: cvs.info,  Node: Editing files,  Next: Watch information,  Prev: Getting Notified,  Up: Watches

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 (*note 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 options 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 [`-lR'] 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 options 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 successfully communicate with
the server; the notifications will be sent upon the next successful CVS
command.


File: cvs.info,  Node: Watch information,  Next: Watches Compatibility,  Prev: Editing files,  Up: Watches

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

 - Command: cvs watchers [`-lR'] 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 options are processed as for the `cvs watch'
     commands.


 - Command: cvs editors [`-lR'] 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 options are processed as for the `cvs watch'
     commands.



File: cvs.info,  Node: Watches Compatibility,  Prev: Watch information,  Up: Watches

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 the following (all on one
line):

     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.


File: cvs.info,  Node: Choosing a model,  Prev: Watches,  Up: Multiple developers

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 a brief description of
some of 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 *Note 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.


File: cvs.info,  Node: Revision management,  Next: Keyword substitution,  Prev: Multiple developers,  Up: Top

Revision management
*******************

   If you have read this far, you probably have a pretty good grasp on
what CVS can do for you.  This chapter talks a little about things that
you still have to decide.

   If you are doing development on your own using CVS you could
probably skip this chapter.  The questions this chapter takes up become
more important when more than one person is working in a repository.

* Menu:

* When to commit::              Some discussion on the subject


File: cvs.info,  Node: When to commit,  Up: Revision management

When to commit?
===============

   Your group should decide which policy to use regarding commits.
Several policies are possible, and as your experience with CVS grows
you will probably find out what works for you.

   If you commit files too quickly you might commit files that do not
even compile.  If your partner updates his working sources to include
your buggy file, he will be unable to compile the code.  On the other
hand, other persons will not be able to benefit from the improvements
you make to the code if you commit very seldom, and conflicts will
probably be more common.

   It is common to only commit files after making sure that they can be
compiled.  Some sites require that the files pass a test suite.
Policies like this can be enforced using the commitinfo file (*note
commitinfo::), but you should think twice before you enforce such a
convention.  By making the development environment too controlled it
might become too regimented and thus counter-productive to the real
goal, which is to get software written.


File: cvs.info,  Node: Keyword substitution,  Next: Tracking sources,  Prev: Revision management,  Up: Top

Keyword substitution
********************

   As long as you edit source files inside a working directory you can
always find out the state of your files via `cvs status' and `cvs log'.
But as soon as you export the files from your development environment
it becomes harder to identify which revisions they are.

   CVS can use a mechanism known as "keyword substitution" (or "keyword
expansion") to help identifying the files.  Embedded strings of the form
`$KEYWORD$' and `$KEYWORD:...$' in a file are replaced with strings of
the form `$KEYWORD:VALUE$' whenever you obtain a new revision of the
file.

* Menu:

* Keyword list::                Keywords
* Using keywords::              Using keywords
* Avoiding substitution::       Avoiding substitution
* Substitution modes::          Substitution modes
* Log keyword::                 Problems with the $Log: cvs.info-4,v $
* Log keyword::                 Problems with the Revision 1.2  2001/09/29 00:00:39  tholo
* Log keyword::                 Problems with the Merge remaining local changes, correct build issues
* Log keyword::                 Problems with the keyword.


File: cvs.info,  Node: Keyword list,  Next: Using keywords,  Up: Keyword substitution

Keyword List
============

   This is a list of the keywords:

`$Author: tholo $'
     The login name of the user who checked in the revision.

`$Date: 2001/09/29 00:00:39 $'
     The date and time (UTC) the revision was checked in.

`$Header: /cvs/OpenBSD/src/gnu/usr.bin/cvs/doc/cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $'
     A standard header containing the full pathname of the RCS file,
     the revision number, the date (UTC), the author, the state, and
     the locker (if locked).  Files will normally never be locked when
     you use CVS.

`$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $'
     Same as `$Header: /cvs/OpenBSD/src/gnu/usr.bin/cvs/doc/cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $', except that the RCS filename is without a path.

`$Name:  $'
     Tag name used to check out this file.  The keyword is expanded
     only if one checks out with an explicit tag name.  For example,
     when running the command `cvs co -r first', the keyword expands to
     `Name: first'.

`$Locker:  $'
     The login name of the user who locked the revision (empty if not
     locked, which is the normal case unless `cvs admin -l' is in use).

`$Log: cvs.info-4,v $
`Revision 1.2  2001/09/29 00:00:39  tholo
`Merge remaining local changes, correct build issues
`'
     The log message supplied during commit, preceded by a header
     containing the RCS filename, the revision number, the author, and
     the date (UTC).  Existing log messages are _not_ replaced.
     Instead, the new log message is inserted after `$Log: cvs.info-4,v $
     Instead, the new log message is inserted after `Revision 1.2  2001/09/29 00:00:39  tholo
     Instead, the new log message is inserted after `Merge remaining local changes, correct build issues
     Instead, the new log message is inserted after `'.  Each
     new line is prefixed with the same string which precedes the
     `$Log' keyword.  For example, if the file contains

            /* Here is what people have been up to:
             *
             * $Log: cvs.info-4,v $
             * Revision 1.2  2001/09/29 00:00:39  tholo
             * Merge remaining local changes, correct build issues
             *
             * Revision 1.1  1997/01/03 14:23:51  joe
             * Add the superfrobnicate option
             *
             */

     then additional lines which are added when expanding the `$Log'
     keyword will be preceded by `   * '.  Unlike previous versions of
     CVS and RCS, the "comment leader" from the RCS file is not used.
     The `$Log' keyword is useful for accumulating a complete change
     log in a source file, but for several reasons it can be
     problematic.  *Note Log keyword::.

`$RCSfile: cvs.info-4,v $'
     The name of the RCS file without a path.

`$Revision: 1.2 $'
     The revision number assigned to the revision.

`$Source: /cvs/OpenBSD/src/gnu/usr.bin/cvs/doc/cvs.info-4,v $'
     The full pathname of the RCS file.

`$State: Exp $'
     The state assigned to the revision.  States can be assigned with
     `cvs admin -s'--see *Note admin options::.


File: cvs.info,  Node: Using keywords,  Next: Avoiding substitution,  Prev: Keyword list,  Up: Keyword substitution

Using keywords
==============

   To include a keyword string you simply include the relevant text
string, such as `$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $', inside the file, and commit the file.  CVS will
automatically expand the string as part of the commit operation.

   It is common to embed the `$Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $' string in the source files so that
it gets passed through to generated files.  For example, if you are
managing computer program source code, you might include a variable
which is initialized to contain that string.  Or some C compilers may
provide a `#pragma ident' directive.  Or a document management system
might provide a way to pass a string through to generated files.

   The `ident' command (which is part of the RCS package) can be used
to extract keywords and their values from a file.  This can be handy
for text files, but it is even more useful for extracting keywords from
binary files.

     $ ident samp.c
     samp.c:
          $Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $
     $ gcc samp.c
     $ ident a.out
     a.out:
          $Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $

   SCCS is another popular revision control system.  It has a command,
`what', which is very similar to `ident' and used for the same purpose.
Many sites without RCS have SCCS.  Since `what' looks for the
character sequence `@(#)' it is easy to include keywords that are
detected by either command.  Simply prefix the keyword with the magic
SCCS phrase, like this:

     static char *id="@(#) $Id: cvs.info-4,v 1.2 2001/09/29 00:00:39 tholo Exp $";


File: cvs.info,  Node: Avoiding substitution,  Next: Substitution modes,  Prev: Using keywords,  Up: Keyword substitution

Avoiding substitution
=====================

   Keyword substitution has its disadvantages.  Sometimes you might
want the literal text string `$Author: tholo $' to appear inside a file without
CVS interpreting it as a keyword and expanding it into something like
`$Author: tholo $'.

   There is unfortunately no way to selectively turn off keyword
substitution.  You can use `-ko' (*note Substitution modes::) to turn
off keyword substitution entirely.

   In many cases you can avoid using keywords in the source, even
though they appear in the final product.  For example, the source for
this manual contains `$@asis{}Author$' whenever the text `$Author: tholo $'
should appear.  In `nroff' and `troff' you can embed the null-character
`\&' inside the keyword for a similar effect.


File: cvs.info,  Node: Substitution modes,  Next: Log keyword,  Prev: Avoiding substitution,  Up: Keyword substitution

Substitution modes
==================

   Each file has a stored default substitution mode, and each working
directory copy of a file also has a substitution mode.  The former is
set by the `-k' option to `cvs add' and `cvs admin'; the latter is set
by the `-k' or `-A' options to `cvs checkout' or `cvs update'.  `cvs
diff' also has a `-k' option.  For some examples, see *Note Binary
files::, and *Note Merging and keywords::.

   The modes available are:

`-kkv'
     Generate keyword strings using the default form, e.g.  `$Revision:
     5.7 $' for the `Revision' keyword.

`-kkvl'
     Like `-kkv', except that a locker's name is always inserted if the
     given revision is currently locked.  The locker's name is only
     relevant if `cvs admin -l' is in use.

`-kk'
     Generate only keyword names in keyword strings; omit their values.
     For example, for the `Revision' keyword, generate the string
     `$Revision: 1.2 $' instead of `$Revision: 1.2 $'.  This option is useful
     to ignore differences due to keyword substitution when comparing
     different revisions of a file (*note Merging and keywords::).

`-ko'
     Generate the old keyword string, present in the working file just
     before it was checked in.  For example, for the `Revision'
     keyword, generate the string `$Revision: 1.2 $' instead of
     `$Revision: 1.2 $' if that is how the string appeared when the
     file was checked in.

`-kb'
     Like `-ko', but also inhibit conversion of line endings between
     the canonical form in which they are stored in the repository
     (linefeed only), and the form appropriate to the operating system
     in use on the client.  For systems, like unix, which use linefeed
     only to terminate lines, this is the same as `-ko'.  For more
     information on binary files, see *Note Binary files::.

`-kv'
     Generate only keyword values for keyword strings.  For example,
     for the `Revision' keyword, generate the string `5.7' instead of
     `$Revision: 1.2 $'.  This can help generate files in programming
     languages where it is hard to strip keyword delimiters like
     `$Revision: 1.2 $' from a string.  However, further keyword
     substitution cannot be performed once the keyword names are
     removed, so this option should be used with care.

     One often would like to use `-kv' with `cvs export'--*note
     export::.  But be aware that doesn't handle an export containing
     binary files correctly.


File: cvs.info,  Node: Log keyword,  Prev: Substitution modes,  Up: Keyword substitution

Problems with the $Log: cvs.info-4,v $
Problems with the Revision 1.2  2001/09/29 00:00:39  tholo
Problems with the Merge remaining local changes, correct build issues
Problems with the keyword.
================================

   The `$Log: cvs.info-4,v $
   The `Revision 1.2  2001/09/29 00:00:39  tholo
   The `Merge remaining local changes, correct build issues
   The `' keyword is somewhat controversial.  As long as you are
working on your development system the information is easily accessible
even if you do not use the `$Log: cvs.info-4,v $
even if you do not use the `Revision 1.2  2001/09/29 00:00:39  tholo
even if you do not use the `Merge remaining local changes, correct build issues
even if you do not use the `' keyword--just do a `cvs log'.  Once
you export the file the history information might be useless anyhow.

   A more serious concern is that CVS is not good at handling `$Log: cvs.info-4,v $
   A more serious concern is that CVS is not good at handling `Revision 1.2  2001/09/29 00:00:39  tholo
   A more serious concern is that CVS is not good at handling `Merge remaining local changes, correct build issues
   A more serious concern is that CVS is not good at handling `'
entries when a branch is merged onto the main trunk.  Conflicts often
result from the merging operation.

   People also tend to "fix" the log entries in the file (correcting
spelling mistakes and maybe even factual errors).  If that is done the
information from `cvs log' will not be consistent with the information
inside the file.  This may or may not be a problem in real life.

   It has been suggested that the `$Log: cvs.info-4,v $
   It has been suggested that the `Revision 1.2  2001/09/29 00:00:39  tholo
   It has been suggested that the `Merge remaining local changes, correct build issues
   It has been suggested that the `' keyword should be inserted
_last_ in the file, and not in the files header, if it is to be used at
all.  That way the long list of change messages will not interfere with
everyday source file browsing.


File: cvs.info,  Node: Tracking sources,  Next: Builds,  Prev: Keyword substitution,  Up: Top

Tracking third-party sources
****************************

   If you modify a program to better fit your site, you probably want
to include your modifications when the next release of the program
arrives.  CVS can help you with this task.

   In the terminology used in CVS, the supplier of the program is
called a "vendor".  The unmodified distribution from the vendor is
checked in on its own branch, the "vendor branch".  CVS reserves branch
1.1.1 for this use.

   When you modify the source and commit it, your revision will end up
on the main trunk.  When a new release is made by the vendor, you
commit it on the vendor branch and copy the modifications onto the main
trunk.

   Use the `import' command to create and update the vendor branch.
When you import a new file, the vendor branch is made the `head'
revision, so anyone that checks out a copy of the file gets that
revision.  When a local modification is committed it is placed on the
main trunk, and made the `head' revision.

* Menu:

* First import::                Importing for the first time
* Update imports::              Updating with the import command
* Reverting local changes::     Reverting to the latest vendor release
* Binary files in imports::     Binary files require special handling
* Keywords in imports::         Keyword substitution might be undesirable
* Multiple vendor branches::    What if you get sources from several places?