• Plan-X
• » Courses
• » Project seminar (Spring 2003)
• » CVS

Resources: The CVS web page; the Version Management with CVS web page.

Example systems: CVS is available directly on most Unix systems. On Windows there is a command-line version available in Cygwin, and as Shell Extension for Windows Explorer in Tortoise CVS.

Basic CVS

• Updating working directory: cvs update.

  To also get newly added directories added, use option -d (or see convenience below).

  Here are some of the common "codes" displayed during update: M (file was modified locally), C (local modifications conflict with repository version), U (file was updated), P (like U but using a patch), A (the file was added), R (the file was removed), and ? (the file is in the working directory, but not in the repository).

• Committing local changes: cvs commit.

  This will fail if the working directory is not up-to-date; in that case, use cvs update first.

File system manipulations

• Adding a file, file.sml, to the repository: cvs add file.sml.

  The file is not in the repository until actually committed.

• Removing a file file.sml from the repository: Make sure the file, file.sml, is not present in the file system (for example, rm file.sml) then cvs remove file.sml.

  The change is not in reflected the repository until actually committed.

  Files removed in this way can later be recovered from the repository.

• Adding a directory, dir, to the repository: cvs add dir.

  Newly added directories need not be committed.

• Removing a directory is not simple. Instead ensure that the directory is empty and that updates have the -P flag (or see convenience below).

Initial things

• Initializing a repository: cvs -d <path> init (where <path> is the path to the desired location of the repository). A directory <path>/CVSROOT will be created, and future modules are added to the repository as <path>/<module dir> where <module dir> is specified during import.

  At this point, either set the environment variable CVSROOT to <path> or use option cvs -d <path> for the import command or the first add command. (Specifiying CVSROOT is not necessary once a file CVS/Root is present in your working directory.)

• Importing existing files: go to the directory containing the files, then do a cvs import <module dir> <module name> start. This will add files and subdirectories to the repository.

• Checking out an existing module: cvs -d <path> checkout <module name> (see above for <path> and <module name>).

  If the repository is on another machine, set CVS_RSH to ssh and do cvs -d :ext:<machine name>:<path> checkout <module name> where <machine name> could be tyr.diku.dk.

Development cycle

Make sure you enforce basic invariants on your CVS usage. For example, "Never commit without checking that compilation is successful and test suite runs without errors.".

A typical development cycle will look like

1. get latest version: cvs update.
2. add feature / fix bug / ...
3. compile / build. failure (compilation failure)? return to 2.
4. run test suite (remember to add test case). failure (test failed)? return to 2.
5. commit to repository: cvs commit. failure (version not up-to-date)? return to 1.

The basic advice is to commit often (but not too often, cf. the invariant) to reduce the number of failures in step 5. and consequent reiterations of the complete cycle.

Convenience

• Eliminate "temporary" files from cvs update output: create a file .cvsignore containing patterns for the files to be eliminated (it could contain, for example, *.uo and *.ui).
• Standard options to cvs: create a file .cvsrc in your home directory containing (for example)

           update -dP
           diff -u
           cvs -q