Spring 2004
The main web resource for CVS is at
http://www.cvshome.org/.
If you wander in that way, be aware that the version we are running in
the lab is 1.11.something.
There is a very brief introduction, CVS for new users, which is especially good if you haven't used any form of revision control before. There is also a somewhat longer Introduction to CVS (of which there is also a printed copy on the CS lab bookshelf).
The full CVS Reference Manual is available online, with pretty reasonable navigation.
CVS commands have the form
cvs [global options] command [command options]
Note that an options has a different meaning in the global section (before the command) from what it does later in the command line.
Two global options are especially good to know:
-H- provide help
-n- do nothing
You can get help from the CVS command with -H, as in
cvs -H cvs -H update
You can use -n to see what a command would
do, without actually doing it. (You might know that -n
has the same meaning for the make command.) So
cvs -n update
will tell you what files would be updated if you left out the -n.
Most revision control systems support some form of branching, so that development can proceed along more than one line. The most common case for this in a production environment is that there may need to be fixes applied to a released version, while development continues independently toward the next planned release. This would be provided by creating a branch for the release, while development continues along the trunk (the main branch).
With CVS, you usually refer to revisions by names that have been assigned
to them. The commands that let you name revisions usually place the name
after a -r option (though sometimes it is another
letter). I gave the name initial to the original
versions you should have checked out. So (assuming you are in the
root directory of your working tree) you can do
cvs diff -r initial
to see how your working tree differs from that revision. (If you want to pipe it through a pager, pipe both stdout and stderr; use
cvs diff -r initial |& less
if you have the default shell in the lab.)
You can give a name to a branch, too, instead of to a specific revision.
If you do, then branch always refers to the latest revision on the branch.
You originally checked out sources from the trunk. You then created a
branch off of the trunk, and you tagged that branch with your user name
(using the command cvs tag). So referring to your branch
will always get the latest version.
Note that some commands that involve tags create 'sticky' tags: the tag information is recorded in your repository. Your working tree should have your branch tag stuck to it. If you try the command
cvs status Makefile
you'll see evidence of the sticky tag on that file.
Sticky tags in your working directory are used if you don't specify otherwise. If, for example, you do
cvs diff
without specifying a revision, it will compare against the latest revision on your branch.
One of the useful features of branching is that it allows you to merge changes from one branch into another. CVS does as much of the merging as it can automatically, with help for the cases it can't handle.
I've checked into the repository some updates that you'll likely find
helpful. (They also provide a chance to learn a bit more about working
with CVS.) The new revisions have the tag base.
Assuming you are in the root directory of your working tree, you can compare your files with what I've checked in by doing the following:
cvs diff -r base |& less
That will give you a full set of diffs.
You can get a little more info (and move closer to merging) with
cvs -n update -d -j base
Note the '-n', which keeps the command from doing anything.
The -d (after update) says to create any
new directories needed, and the -j base specifies a merge
from my revisions.
This will produce two kinds of messages. One kind starts with an
uppercase letter or ?, indicating the status of that file. The
common cases are:
?- CVS doesn't know about the file
U- an Updated version is in the repository
M- you've Modified the file
A- you've Added, but not committed, the file (Don't worry if you don't yet know what that means.)
The other messages will be about merges, for files that have changed in
the other branch and need to be updated by merging the changes. You
should see an update to PL365Parser.jj and
.cvsignore, plus some ? and merging lines.
Do the merge for real now, by leaving the -n out of
the command. Watch
carefully for messages about conflicts. (There shouldn't be any.) Then
type the command
touch MergeDate
This will create a file MergeDate in the current
directory with the current time. That timestamp will be a useful
thing to have if you need to merge again in the future.
The update includes files named .cvsignore, which contain
a list of files that CVS should ignore. I've added the jtb- and
javacc-generated files, plus those
created by my version of the Makefile. That will make
future runs of cvs update less noisy.
Last modified: Mon Apr 5 13:24:40 CDT 2004