This is cvs.info, produced by makeinfo version 4.5 from cvs.texinfo.
INFO-DIR-SECTION GNU Packages
START-INFO-DIR-ENTRY
* CVS: (cvs). Concurrent Versions System
END-INFO-DIR-ENTRY
INFO-DIR-SECTION Individual utilities
START-INFO-DIR-ENTRY
* cvs: (cvs)CVS commands. Concurrent Versions System
END-INFO-DIR-ENTRY
File: cvs.info, Node: Recursive behavior, Next: Adding and removing, Prev: Branching and merging, Up: Top
Recursive behavior
******************
Almost all of the subcommands of CVS work recursively when you
specify a directory as an argument. For instance, consider this
directory structure:
`$HOME'
|
+--tc
| |
+--CVS
| (internal CVS files)
+--Makefile
+--backend.c
+--driver.c
+--frontend.c
+--parser.c
+--man
| |
| +--CVS
| | (internal CVS files)
| +--tc.1
|
+--testing
|
+--CVS
| (internal CVS files)
+--testpgm.t
+--test2.t
If `tc' is the current working directory, the following is true:
* `cvs update testing' is equivalent to
cvs update testing/testpgm.t testing/test2.t
* `cvs update testing man' updates all files in the subdirectories
* `cvs update .' or just `cvs update' updates all files in the `tc'
directory
If no arguments are given to `update' it will update all files in
the current working directory and all its subdirectories. In other
words, `.' is a default argument to `update'. This is also true for
most of the CVS subcommands, not only the `update' command.
The recursive behavior of the CVS subcommands can be turned off with
the `-l' option. Conversely, the `-R' option can be used to force
recursion if `-l' is specified in `~/.cvsrc' (*note ~/.cvsrc::).
$ cvs update -l # Don't update files in subdirectories
File: cvs.info, Node: Adding and removing, Next: History browsing, Prev: Recursive behavior, Up: Top
Adding, removing, and renaming files and directories
****************************************************
In the course of a project, one will often add new files. Likewise
with removing or renaming, or with directories. The general concept to
keep in mind in all these cases is that instead of making an
irreversible change you want CVS to record the fact that a change has
taken place, just as with modifying an existing file. The exact
mechanisms to do this in CVS vary depending on the situation.
* Menu:
* Adding files:: Adding files
* Removing files:: Removing files
* Removing directories:: Removing directories
* Moving files:: Moving and renaming files
* Moving directories:: Moving and renaming directories
File: cvs.info, Node: Adding files, Next: Removing files, Up: Adding and removing
Adding files to a directory
===========================
To add a new file to a directory, follow these steps.
* You must have a working copy of the directory. *Note Getting the
source::.
* Create the new file inside your working copy of the directory.
* Use `cvs add FILENAME' to tell CVS that you want to version
control the file. If the file contains binary data, specify `-kb'
(*note Binary files::).
* Use `cvs commit FILENAME' to actually check in the file into the
repository. Other developers cannot see the file until you
perform this step.
You can also use the `add' command to add a new directory.
Unlike most other commands, the `add' command is not recursive. You
have to expcicitly name files and directories that you wish to add to
the repository. However, each directory will need to be added
separately before you will be able to add new files to those
directories.
$ mkdir -p foo/bar
$ cp ~/myfile foo/bar/myfile
$ cvs add foo foo/bar
$ cvs add foo/bar/myfile
- Command: cvs add [`-k' kflag] [`-m' message] files ...
Schedule FILES to be added to the repository. The files or
directories specified with `add' must already exist in the current
directory. To add a whole new directory hierarchy to the source
repository (for example, files received from a third-party
vendor), use the `import' command instead. *Note import::.
The added files are not placed in the source repository until you
use `commit' to make the change permanent. Doing an `add' on a
file that was removed with the `remove' command will undo the
effect of the `remove', unless a `commit' command intervened.
*Note Removing files::, for an example.
The `-k' option specifies the default way that this file will be
checked out; for more information see *Note Substitution modes::.
The `-m' option specifies a description for the file. This
description appears in the history log (if it is enabled, *note
history file::). It will also be saved in the version history
inside the repository when the file is committed. The `log'
command displays this description. The description can be changed
using `admin -t'. *Note admin::. If you omit the `-m
DESCRIPTION' flag, an empty string will be used. You will not be
prompted for a description.
For example, the following commands add the file `backend.c' to the
repository:
$ cvs add backend.c
$ cvs commit -m "Early version. Not yet compilable." backend.c
When you add a file it is added only on the branch which you are
working on (*note Branching and merging::). You can later merge the
additions to another branch if you want (*note Merging adds and
removals::).
File: cvs.info, Node: Removing files, Next: Removing directories, Prev: Adding files, Up: Adding and removing
Removing files
==============
Directories change. New files are added, and old files disappear.
Still, you want to be able to retrieve an exact copy of old releases.
Here is what you can do to remove a file, but remain able to
retrieve old revisions:
* Make sure that you have not made any uncommitted modifications to
the file. *Note Viewing differences::, for one way to do that.
You can also use the `status' or `update' command. If you remove
the file without committing your changes, you will of course not
be able to retrieve the file as it was immediately before you
deleted it.
* Remove the file from your working copy of the directory. You can
for instance use `rm'.
* Use `cvs remove FILENAME' to tell CVS that you really want to
delete the file.
* Use `cvs commit FILENAME' to actually perform the removal of the
file from the repository.
When you commit the removal of the file, CVS records the fact that
the file no longer exists. It is possible for a file to exist on only
some branches and not on others, or to re-add another file with the same
name later. CVS will correctly create or not create the file, based on
the `-r' and `-D' options specified to `checkout' or `update'.
- Command: cvs remove [options] files ...
Schedule file(s) to be removed from the repository (files which
have not already been removed from the working directory are not
processed). This command does not actually remove the file from
the repository until you commit the removal. For a full list of
options, see *Note Invoking CVS::.
Here is an example of removing several files:
$ cd test
$ rm *.c
$ cvs remove
cvs remove: Removing .
cvs remove: scheduling a.c for removal
cvs remove: scheduling b.c for removal
cvs remove: use 'cvs commit' to remove these files permanently
$ cvs ci -m "Removed unneeded files"
cvs commit: Examining .
cvs commit: Committing .
As a convenience you can remove the file and `cvs remove' it in one
step, by specifying the `-f' option. For example, the above example
could also be done like this:
$ cd test
$ cvs remove -f *.c
cvs remove: scheduling a.c for removal
cvs remove: scheduling b.c for removal
cvs remove: use 'cvs commit' to remove these files permanently
$ cvs ci -m "Removed unneeded files"
cvs commit: Examining .
cvs commit: Committing .
If you execute `remove' for a file, and then change your mind before
you commit, you can undo the `remove' with an `add' command.
$ ls
CVS ja.h oj.c
$ rm oj.c
$ cvs remove oj.c
cvs remove: scheduling oj.c for removal
cvs remove: use 'cvs commit' to remove this file permanently
$ cvs add oj.c
U oj.c
cvs add: oj.c, version 1.1.1.1, resurrected
If you realize your mistake before you run the `remove' command you
can use `update' to resurrect the file:
$ rm oj.c
$ cvs update oj.c
cvs update: warning: oj.c was lost
U oj.c
When you remove a file it is removed only on the branch which you
are working on (*note Branching and merging::). You can later merge
the removals to another branch if you want (*note Merging adds and
removals::).
File: cvs.info, Node: Removing directories, Next: Moving files, Prev: Removing files, Up: Adding and removing
Removing directories
====================
In concept removing directories is somewhat similar to removing
files--you want the directory to not exist in your current working
directories, but you also want to be able to retrieve old releases in
which the directory existed.
The way that you remove a directory is to remove all the files in
it. You don't remove the directory itself; there is no way to do that.
Instead you specify the `-P' option to `cvs update' or `cvs checkout',
which will cause CVS to remove empty directories from working
directories. (Note that `cvs export' always removes empty directories.)
Probably the best way to do this is to always specify `-P'; if you want
an empty directory then put a dummy file (for example `.keepme') in it
to prevent `-P' from removing it.
Note that `-P' is implied by the `-r' or `-D' options of `checkout'.
This way CVS will be able to correctly create the directory or not
depending on whether the particular version you are checking out
contains any files in that directory.
File: cvs.info, Node: Moving files, Next: Moving directories, Prev: Removing directories, Up: Adding and removing
Moving and renaming files
=========================
Moving files to a different directory or renaming them is not
difficult, but some of the ways in which this works may be non-obvious.
(Moving or renaming a directory is even harder. *Note Moving
directories::.).
The examples below assume that the file OLD is renamed to NEW.
* Menu:
* Outside:: The normal way to Rename
* Inside:: A tricky, alternative way
* Rename by copying:: Another tricky, alternative way
File: cvs.info, Node: Outside, Next: Inside, Up: Moving files
The Normal way to Rename
------------------------
The normal way to move a file is to copy OLD to NEW, and then issue
the normal CVS commands to remove OLD from the repository, and add NEW
to it.
$ mv OLD NEW
$ cvs remove OLD
$ cvs add NEW
$ cvs commit -m "Renamed OLD to NEW" OLD NEW
This is the simplest way to move a file, it is not error-prone, and
it preserves the history of what was done. Note that to access the
history of the file you must specify the old or the new name, depending
on what portion of the history you are accessing. For example, `cvs
log OLD' will give the log up until the time of the rename.
When NEW is committed its revision numbers will start again, usually
at 1.1, so if that bothers you, use the `-r rev' option to commit. For
more information see *Note Assigning revisions::.
File: cvs.info, Node: Inside, Next: Rename by copying, Prev: Outside, Up: Moving files
Moving the history file
-----------------------
This method is more dangerous, since it involves moving files inside
the repository. Read this entire section before trying it out!
$ cd $CVSROOT/DIR
$ mv OLD,v NEW,v
Advantages:
* The log of changes is maintained intact.
* The revision numbers are not affected.
Disadvantages:
* Old releases cannot easily be fetched from the repository. (The
file will show up as NEW even in revisions from the time before it
was renamed).
* There is no log information of when the file was renamed.
* Nasty things might happen if someone accesses the history file
while you are moving it. Make sure no one else runs any of the CVS
commands while you move it.
File: cvs.info, Node: Rename by copying, Prev: Inside, Up: Moving files
Copying the history file
------------------------
This way also involves direct modifications to the repository. It
is safe, but not without drawbacks.
# Copy the RCS file inside the repository
$ cd $CVSROOT/DIR
$ cp OLD,v NEW,v
# Remove the old file
$ cd ~/DIR
$ rm OLD
$ cvs remove OLD
$ cvs commit OLD
# Remove all tags from NEW
$ cvs update NEW
$ cvs log NEW # Remember the non-branch tag names
$ cvs tag -d TAG1 NEW
$ cvs tag -d TAG2 NEW
...
By removing the tags you will be able to check out old revisions.
Advantages:
* Checking out old revisions works correctly, as long as you use
`-rTAG' and not `-DDATE' to retrieve the revisions.
* The log of changes is maintained intact.
* The revision numbers are not affected.
Disadvantages:
* You cannot easily see the history of the file across the rename.
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
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, 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 tags,
use the `taginfo' file (*note taginfo::). 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'.
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$' > 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$' > 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. (Note that you can use `cvs log' to
determine the default keyword substitution method for a file and `cvs
status' to determine the keyword substitution method for a working
copy.)
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.
Unresolved Conflict
A file with the same name as this new file has been added to the
repository from a second workspace. This file will need to be
moved out of the way to allow an `update' to complete.
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', to remind developers to use the `cvs edit' command.
- Command: cvs watch add [`-lR'] [`-a' ACTION]... [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 watched file.
`commit'
Another user has committed changes to one of the named FILES.
`unedit'
Another user has abandoned editing a file (other than by
committing changes). They can do this in several ways, by:
* applying the `cvs unedit' command (described below) to
the file
* applying the `cvs release' command (*note release::) to
the file's parent directory (or recursively to a
directory more than one level up)
* deleting the file and allowing `cvs update' to recreate
it
`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 `cvs watch on'.
- Command: cvs watch remove [`-lR'] [`-a' ACTION]... [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 [`-lR'] [`-a' ACTION]... [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 the 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 with the
command `cvs update -C file' (*note update::). The meaning is not
precisely the same; the latter 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