UMBC CMSC431, Compiler Design Principles, Fall 2009

Using CVS to Submit Projects


CVS is a popular free revision control system. It is designed to allow one or more people to work on the same project, keeping checked in versions of files in a common repository. Its main use is for managing source code in projects with multiple developers, and it includes some pretty nifty support for merging independent changes to text files. In fact, using some sort of revision control is almost required for any reasonably complex software project. The revision tracking features are pretty handy even when working alone. You can go back to any revision of your files that was ever checked into the repository, either by revision number or date.

In our case, you will be checking in your project files, and the instructor will be checking them out to grade. I encourage you to check in changes often, but in the end you just need to make sure the required files are checked in for each project by the deadline.

Initial checkout

First, you must check out your directory from the repository. This will give you your own working copy of any files supplied by the instructors for the project as well as files needed by CVS to manage your code properly. Do not attempt to work directly in the repository, CVS will get quite confused if you do this, and I probably won't be able to check out your code to grade it. On the GL systems, you'd use a command like this:

cvs -d /afs/ checkout -d MyProj1 user1
where you substitute Proj1, MyProj1 and user1 with the appropriate project name, local directory name and user name, respectively. This CVS command will create a directory called 'MyProj1' in your current directory. If any files are distributed with the project, those files will be copied to 'MyProj1'. CVS will also create a subdirectory called 'CVS' where CVS keeps a bunch of housekeeping data. This is the only time you need to tell CVS where the repository is. After the intial checkout, once you cd into your newly created directory (in this case, MyProj1), CVS can figure out which repository to use. All of the major CVS commands apply to the current directory and all directories under it.


Edit away... No need to do anything special

Adding, removing, and ignoring files

If you add files, such as a new .java file, you need to let CVS know so they'll be checked in:

cvs add file

To tell CVS you're removing a file (so it won't come back next time you update — see below):

cvs remove -f file

To tell CVS to ignore a file add it to the list in the .cvsignore file (which you'll need to create with a text editor if you want to use this functionality of CVS) in that directory.

Checking in your changes

Your changed or added files are not copied to the repository until you check them in. You must do this for us to be able to check out and grade your work, but you can do it as many times as you want before then. First do this:

cvs -q update

Files CVS doesn't know about will be listed with a '?'. Next, tell CVS to add or ignore each of them, then try the update again. It's good practice to make sure CVS knows about every file before you commit any check in.

Now check them into the repository:

cvs commit

An editor will pop up, showing you a listing of what will be checked in. You can enter a log message here to say what was in the checkin. This message is for you: We will not look at the log messages for grading, but it can be useful if you want to look back at old versions later. You can change editors by setting the EDITOR environment variable (the default editor is vi), but whatever editor you use must not normally return to a prompt right away, and you must quit that instance of the editor after writing your log message for the commit to complete. (CVS tells that you're done editing the log message when the editor returns)

If you'd rather not have the editory pop up, and have a short log message, you can specify it on the command line as follows:
cvs commit -m 'the log message'

Now check to make sure it worked:

cvs -q update

This time, it shouldn't list any files. If it does, something went wrong. Make sure you've told CVS to add or ignore if necessary, and try again, or ask for help. The first time you check in, you may want to follow the checkout directions to make a second copy (under a different name), just to see what we'll get.

Getting updates and previous revisions

If we make any changes to files we supply (or add some for the later assignments), you can get these using

cvs update -d

You can compare your current file with any previous version (dates are GMT; for a local date, use something like '1/1/05 13:15 EST')

cvs diff -D date file

To figure out which revision is which (assuming you entered reasonable log messages when you committed your changes), do

cvs log file

You can actually get a full copy of an old file revision with

cvs update -D date file

but be careful with this; CVS remembers that you went back in time and will refuse to check in changes you make to the old file. To get back to the latest version, do

cvs update -A file

If you just want to throw away your current edits to start again from the last checked-in version, just remove the file and re-update. If you want to toss several revisions, go ahead and do the -D, make a copy, do the -A, then replace the file with your copied old revision.

Over SSH

You can run CVS remotely over SSH to exchange files between your own machine and the repository. This is only useful if your machine is running Linux on an Intel compatible CPU. Here's what you do. Add the following to your .tcshrc or .cshrc file:
setenv CVS_RSH ssh
(If you are not using tcsh or csh for your shell, use the analogous commands to set the CVS_RSH environment variable.) Add the prefix to the beginning of the repository pathname for the initial checkout, like so:
cvs -d checkout -d MyProj1 user1
You'll be prompted for your UMBC password. After the initial checkout, use CVS as usual.

Learning more

List of all CVS commands

cvs help

Help on any one CVS command

cvs --help command
The CVS manual is available from a UNIX shell:
info cvs
or from

General CVS manuals, downloads, etc.:


This document was taken almost entirely from the Spring 2009 CMSC341 CVS submission page which was in turn has the vast majority of its verbiage taken verbatim from Marc Olano's instructions on how to use CVS for submitting class projects.

Last Modified: 21 Sep 2009 09:29:13 EDT by Richard Chang
to Fall 2009 CMSC 431 Homepage