wiki:UsingCVS
Last modified 11 years ago Last modified on 05/08/06 13:34:25

In order to use CVS you have to

  1. Have a valid account on the SIG Linux machines
  2. Be a member of the group cvs-user (try the command groups to list the groups you are a member of)

Contact JoshuaDF if these conditions don't hold.

You can view the SIG CVS repository on the web at http://sig.biostr.washington.edu/viewcvs/viewcvs.cgi/src/

A Brief Introduction to CVS

For those not familiar with CVS, I'll attempt a brief introduction to the Concurrent Versions System. CVS is meant to be both a source code repository, and a system to manage (possibly) many people working on the same file(s) at once. The system works as follows: to start working on some code, you do a 'checkout', which will download a current copy of the code from the repository, and create a subdirectory (named 'CVS' within each directory to store status info, etc. When you have made changes to your copy of the code (this is called the "working repository"), and want to submit it back into the repository, you first run an 'update', which will make sure that no one has been working on the same part of the file(s) as you have been since the checkout. You will need to fix any conflicts arising from this situation that CVS can't fix on its own, but rest assured that this rarely happens (and when it does, it shouldn't have; this would imply poor or a lack of communication between people editing the files). Once past the update (which, again, is generally a painless operation), you are ready to 'commit' the files.

Here's where the important part comes: While CVS will let you submit massive changes across many files at once, this is NOT the way it was designed to work. Unless all the files you have changed were changed for the same reason, don't commit them all at the same time!!! I cannot stress that any more. Doing so will allow us to easily track changes made to code (and, however unlikely, undo changes made). CVS will prompt you for a brief description of what you have done to the files you that are submitting, and you will want the statement to be true of all files, meaning that if you have three files that needed to be updated for the same reason, and you (so observantly!) found a typo in a fourth file that you fixed, commit the changes separately; that typo doesn't have anything to do with the changes you made in the first three files!

CVS within SIG

The SIG CVS repository holds all source code that has matured into a usable form in addition to the files for the SIG webpages. Generally when your code has become "stable" (a very relative, subjective term), you have ceased development on it and/or you are parting ways with the group, you will want to have your work imported into the CVS repository. You should, however, consider having your code imported as soon as it becomes relatively stable, as developing with CVS allows you to track your changes and essentially "undo" changes made in error (note that commiting files individually and in small increments is paramount in this role).

Actually Using CVS

Now, of course, you are eager to get started on working with CVS to make your life (and ours) easier. You will have several options for using CVS, depending on your platform and your familiarity with the command line. For Windows machines, we use TortoiseCVS, an entirely graphical interface to CVS using contextual menus (right-click menus) in the Windows Explorer. Read the UsingTortoiseCVS page for the details. There is also "CVS for NT" for those wanting a command line. Other GUI programs, such as WinCVS and the likes are available, but TortoiseCVS should be sufficient for most CVS purposes and is by far the easiest and simplest to learn and use.

Setting Up CVS on Linux

For the Linux camp, there is, of course, the command line. Otherwise, we have LinCVS and Cervisia. LinCVS is probably more appropriate, as it is much more configurable. Since you are using Linux, you are probably going to just use the command line anyway (it's not that bad).

These docs also assume you have the environment variables CVSROOT and CVS_RSH set appropriately. For most (ie, those using the bash shell), this can be done by adding these lines to the file .bashrc in your home directory:

export CVSROOT=:ext:$USER@cvs.biostr.washington.edu:/usr/local/cvsroot
export CVS_RSH=ssh

You will have to log out and back in to have the file be reread, or you can simply type the commands at the command prompt for the current session. To find out if these are already set type env or echo $CVSROOT.

If you have chosen csh or tcsh as your default shell, you will instead have to add to .cshrc:

    setenv CVSROOT cvs:/usr/local/cvsroot
    setenv CVS_RSH ssh

Use printenv from the command line to see if it is set.

Import example

The first time you put something in CVS it's easier to do cvs import instead of adding each file. That command will upload all the files in the current directory, while cvs add just does one at a time. For cvs import you also have to give it a description, so, you could do:

cd ~/directory/with/your/source/
cvs import -m "your message" src/projectname $USER firstimport

After this you should check the copy out so you get all the CVS metadata, and then work with it as any CVS tree:

cd ~/someplace/
cvs checkout src/projectname