15-815 Automated Theorem Proving

CVS

The project implementation groups will use the CVS version control system to track and coordinate the sources. Below are some notes about the things I found personally useful to organize contributors to a project. It is probably worthwile to read at least the most important part of the official documentation if you have never used CVS before.

Documentation

Manual in HTML format in CMU/CS misc collection.
C-h i m cvs in Emacs to browse documentation in Info mode.

Policy Recommendations

Do not use watches or locks.
Avoid branches.
Do not use keyword substitution.
Use e-mail to coordinate major changes and conflicts.
Tag only meaningful stable intermediate versions.

Repository

The repository is at /afs/cs.cmu.edu/user/fp/courses/atp/CVS. Invoke CVS using the -d flag when you first check out your project code:

   % cvs -d /afs/cs.cmu.edu/user/fp/courses/atp/CVS checkout color

The checkout command will create a subdirectory color with the current state of the code. Once you have created the local copy, the -d argument is no longer necessary on other operations performed in that directory.

Authentication

You need to be authenticated to the CS cell before you can check out or check in changes. See the CMU/CS help page on cross-realm authentication.

I have created groups fp:red, fp:green, and fp:blue in cell cs.cmu.edu and give appropriate access rights to the repository to these groups. To examine the current membership call

   % pts members fp:color

Common Operations

Below are some common operations, for quick reference.

Checking out sources

   % cvs -d /afs/cs.cmu.edu/user/fp/courses/atp/CVS checkout color

will create or update the subdirectory color with a copy of sources which must then be compiled. There is no locking, and the sources are read/write.

Editing and updating sources

Edit the sources. To obtain changes committed by others, invoke

  % cvs update -d

in the source directory or just the directory which you want to update. The -d flag ensures that you will see new directories, which would otherwise be ignored. If there is a conflict, you might have to edit the result by hand.

Committing changes

Please make sure your sources are up-to-date, compile, and perhaps even pass the standard test suite. The commit your changes with

  % cvs commit -m "brief comment"

for all in the current directory and its subdirectories.

Tagging versions

At the end of each week, when you have generated a stable, working version, the whole source tree of your project group should be tagged with

  % cvs tag weekn

Adding a file or directory

First create the file, then invoke

  % cvs add file

You can add several files at once, but a directory must be added before the file in it. The repository will see the changes at the next commit operation.

Deleting a file

First delete the file, then invoke

  % cvs remove FILE

The repository will see the changes at the next commit operation. Directories cannot be deleted conveniently.

Renaming a file or directory

First rename the file from old to new, then invoke

  % cvs remove old
  % cvs add new

Checking whether sources have changed

  % cvs -n -q update -d   (what has changed in repository)
  % cvs -n commit         (what would happen on commit)

Ignoring generated files

To ignore generated binary directories, the entry

CM

has been added to the $CVSROOT/CVSROOT/cvsignore file. You may add .csvignore files to directories to avoid warnings about other generated files.

Frank Pfenning

fp@cs