CVS (and Subversion) Cheat Sheet

I originally wrote this for a group of students doing a university project; the commands described below should be enough to get you started with CVS, and you can refer to the other documentation for more information.

The best resource I've found for CVS is Open Source Development With CVS, informally "The CVS Book". (It's also available as a real book, but all the important information is there.) I suggest you have a read through that, since it'll cover this stuff in far more depth. At the very least, make sure you read An Overview Of CVS, since that explains in a couple of pages what terms like "repository" mean. For these instructions, I'm assuming you're working on a shared Unix-like system; there's nothing to stop you from keeping a working copy on your machine and using CVS over ssh to get at the shared repository, however (see below). CVS for Windows is available for free from Cygwin.

Basic CVS operations
Using CVS over a network link via SSH
So I want to use Subversion instead...
Using Subversion

Basic CVS operations

Suppose you have a CVS repository in /usr/local/proj/co508/project/hserver/repos. To use this directly from the machine it's on, you'll need to set your CVSROOT environment variable appropriately; if you're using bash type:

export CVSROOT=/usr/local/proj/co508/project/hserver/repos

To create a new repository (you won't need to do this unless you want to play with CVS in a new repository, for instance on your own machine, in which case you should set CVSROOT differently):

cvs init

To import a tree of files into a new CVS project, first change into the directory that you want to import, then do this (projname should be a short name for the project, vendortag will probably be your username; releasetag should probably be start):

cvs import projname vendortag releasetag

Note that this, like many CVS commands, will pop up an editor asking for comments on the checkin. The default editor will probably be vi; if you don't like vi (and I don't blame you), then type something like this to use a different editor:

export EDITOR=pico

To check out a working copy of project projname (into a directory called projname):

cvs checkout projname

To get the latest changes from the repository into your copy (it won't overwrite any files you've modified -- it'll print an M by your modified files):

cvs update

update will also tell you about any conflicts between your changes and changes other people have made to the repository in the mean time.

To show the differences between your working copy and the repository in "context diff" format (see the cvsbook for more details):

cvs -Q diff -c

To check ("commit") your changes back into the repository:

cvs commit

To view the CVS log entries:

cvs log

To add a new file to the project:

cvs add somefile
cvs commit somefile

To add a new empty directory to the project:

mkdir somedir
cvs add somedir

To remove a file from the project:

rm somefile
cvs remove somefile
cvs commit somefile

(Likewise for a directory; you must remove all the files in it first.)

Renaming files in CVS needs a change to be made by hand in the repository; you probably won't need to do this very often, but the procedure is described in the cvsbook.

Using CVS over a network link via SSH

To run CVS on your machine, assuming your username is xyz5, you'll need to do something like:

export CVS_RSH=ssh
export CVSROOT=:ext:xyz5@raptor.ukc.ac.uk:/usr/local/proj/co508/project/hserver/repos

then the normal CVS commands will work as they do on the shared machine. You will probably want to set up an ssh keypair so you don't have to type your password for each command.

So I want to use Subversion instead...

Before jumping straight into Subversion (or CVS, for that matter), I would recommend that you have a look at the more modern distributed version control systems, particularly if you're a team of students working independently or have intermittent Internet access.

I don't recommend Subversion because it's significantly less flexible than the modern distributed version control systems, and maintains several of the disadvantages of CVS (no disconnected operation, no private branches, repositories can't be published without a special server) while still being different enough from CVS that a significant amount of relearning is required.

If you're going to learn a new version control system, then I think it's worth looking at some of the distributed systems, and seeing whether they'd fit your development model better. I use Darcs for several of the projects I'm involved with; Git is also popular.

Subversion does have advantages, though: in particular, there are more external tools that work with Subversion.

Using Subversion

Here's how to set up a Subversion repository on raptor and access it remotely. Before doing this, though, ask the cs-sysadmins whether you can use CSProjects for your project (which'll give you ready-made Subversion and Trac instances, and generally save you a lot of work).

As with CVS, there's a good online reference book available: Version Control with Subversion.

The Subversion version control system has gone through a number of revisions: there are several types of repository and several different ways of accessing them. You want an fsfs repository (since it's not backed by a database, and works over NFS storage) and you'll be accessing it using the svnserve method (since that doesn't require setting up a webserver, which you couldn't do on raptor anyway).

Suppose you want to put a Subversion repository in /usr/local/proj/myproject/project. To create the repository, you'd ssh into raptor and type:

svnadmin create --fs-type fsfs /usr/local/proj/myproject/project

To access the repository, the corresponding URL will be svn+ssh://ats1@raptor.kent.ac.uk/usr/local/proj/myproject/project. (Don't forget to use your own username rather than ats1 there; again, you will probably want to set up an SSH key to avoid typing your password several times for each access.) You can check it out using:

svn co svn+ssh://ats1@raptor.kent.ac.uk/usr/local/proj/myproject/project

... which'll result in an empty directory called project (because you haven't added any files yet). If you change into that directory you'll then be able to use regular svn commands to update, add files, commit, and so on.