HomeDownloadsUser GuideDevelopmentLegal

Development: CVS Primer

This document gives a short introduction to the Concurrent Versions System (CVS) used to manage the source code.

Documentation

There is a lot of documentation available on how to use CVS. Recommended links include:

You will find a description of the most common usage patterns of the CVS commandline client (for the Unix/Mac OS X platform) below.

If you use a graphical CVS client or an IDE like Eclipse please refer to the documentation of your CVS client or IDE instead.

Initial Configuration

~/.cvspass

When CVS is used to access a CVS server over the network it tries to send a password to the remote system. This password is usually taken from the ~/.cvspass file in the users home directory. If there is no such file the cvs command will print a warning message. To suppress that message run the following commands.

$ touch ~/.cvspass
$ chmod go-rwx ~/.cvspass

The above sequence creates an empty ~/.cvspass file that is readable only by the user to ensure that password that are written to this file later on cannot be read by someone else.

~/.cvsrc

Many cvs options are needed or wanted every time cvs is used. Therefore cvs reads in default options from the startup file ~/.cvsrc. The following ~/.cvsrc file may serve as an initial version:

$ cvs -z3 -q
$ update -Pd
$ checkout -P
$ diff -uw

Meaning:

cvs -z3 -q:
-z3: Always compress files that are transferred across the network use gzip(1) with compression level 3. This compression level gives a good compromise between usage of network and computing power.
-q causes cvs to be somewhat quiet.
update -Pd
-d: Whenever an update is made directories, that are new in the repository should checked out automatically.
-P: Prune (remove) directories (from your checked out copy) that are empty after being updated.
checkout -P
-P: Prune (remove) directories (from your checked out copy) that are empty after the checkout.
diff -uw
-w: While showing differences between different versions of the same file ignore all blanks (SPACE and TAB characters) and treat all other strings of blanks as equivalent. For example, 'if ( a == b )' will compare equal to 'if(a==b)' and no differences would be shown. This option makes it easier to see the "real" diffrences after cleaning up the source code.
-u: Show three lines of context around the changed code.

Common Usage Patterns

Update

Updating your copy of the repository with the most current version is probably the most important task. Updates are always done with the CVS sub command update. If one or more files are given as arguments only these files and directories will be updated, otherwise the current working directory is updated. Usually it is good practice to start the update recursively from the top level directory of the project. Given that the above ~/.cvsrc file is used the following command sequence will update your whole project.

$ cvs update

Due to the ~/.cvsrc file the last command expands to cvs -z3 -q update -Pd and the whole project directory will be updated at once. For each file that is newly created or updated in your copy or changed locally you will get one line of output starting with a single letter expressing the concrete status of the file (see table 1 for details) ant a file name.

Table 1: Status of files
FlagDescription
U The file was brought up to date with respect to the repository. This is done for any file that exists in the repository but not in your source, and for files that you haven't changed but are not the most recent versions available in the repository.
A The file has been added to your private copy of the sources, and will be added to the source repository when you run 'cvs commit' on the file. This is a reminder to you that the file needs to be committed.
R The file has been removed from your private copy of the sources, and will be removed from the source repository when you run 'cvs commit' on the file. This is a reminder to you that the file needs to be committed.
M The file is modified in your working directory. 'M' can indicate one of two states for a file you're working on: either there were no modifications to the same file in the repository, so that your file remains as you last saw it; or there were modifications in the repository as well as in your copy, but they were merged successfully, without conflict, in your working directory.
C A conflict was detected while trying to merge your changes to file with changes from the source repository. file (the copy in your working directory) is now the result of merging the two versions; an unmodified copy of your file is also in your working directory, with the name '.#file.version', where version is the revision that your modified file started from. (Note that some systems automatically purge files that begin with '.#' if they have not been accessed for a few days. If you intend to keep a copy of your original file, it is a very good idea to rename it.)
? The file is in your working directory, but does not correspond to anything in the source repository, and is not in the list of files for cvs to ignore. It should either be added or put on the list of files to be ignored.

Sometimes it happens that someone else has changed a file and checked it in that has been modified by you, too. CVS tries to merge these changes together. Most of the time these merges succeed. But if the same lines of code have been change by you and someone else the merge cannot be done automatically and CVS creates a so-called conflict file. The file is also marked by a 'C' in the output of cvs update.

The conflicts in the conflict files have to be resolved manually. This can be done either with an editor or with the use of some merge utility (e.g. tkdiff -conflict <conflict file>).

Checkin

Before you can successfully check in your changes three preconditions have to be met:

  1. Your copy has to be up to date. Therefore the command cvs update has to be used (in the top level directory of the project).
  2. If there are files marked by a question mark in the output of the update command, these file have to be treated:
    1. All new file (and directories) have to be added explicitly by the command cvs add <file>.
    2. All removed file have to be removed explicitly by the command cvs remove <file>.
    3. Eventually you also have to add some files to a .cvsignore file to tell CVS that these file should be ignored.
  3. Your copy of the project directory should be "correct". I.e. it has to compile and all unit test should succeed.

Since updates may change the code (and the correctness of the code) the above two steps might be needed to be done more than once. Finally the output of cvs update shouldn't have any lines marked by an 'U' or '?'.

When you are done with the cycle of updating and building (build world) the project the checking can be done. Therefore change to the top level directory of the project and run cvs commit.