CVS - Concurrent Versioning System

Introduction

CVS is a full-featured version control system, used for years in the TCB Group for managing its software development packages (VMD, NAMD, etc). It can also be used for managing LaTeX files for major reports and proposals and our group bibliography files, replacing RCS.

Rather than trying to re-invent the CVS documentation, new users are encouraged to review the man pages and other documentation:

Further information is available on the CVS homepage, or in "Pragmatic Version Control: Using CVS The Pragmatic Starter Kit - Volume 1" in the TCB Library.

Using CVS with TCB Reports

The first step for using our CVS tree to get the shared group information is to get the files from the tree to a local directory. On our local systems, this is done as so: 

  setenv CVSROOT /home/cvs/groupfiles
  cvs checkout REPORTNAME

If you are on a non-TCB system and want access to the files, you can 

  setenv CVS_RSH ssh
  setenv CVSROOT login.ks.uiuc.edu:/home/cvs/groupfiles
  cvs checkout REPORTNAME

We also have a shared 'bibfiles' tree, which is used for all of our bibliography information, in and out of our reports. To use this, you can download it the same way, using 'bibfiles' in place of 'REPORTNAME'. 

  cd REPORTNAME
  cvs checkout bibfiles

This will check out all current files in the CVS directory. The files are checked out into REPORTNAME/. You can then modify the files in this directory and run make checkin to update the files globally.

Using CVS with TCB Bibliography

If you just want to work on the bibliography in place, run this: 

  setenv CVSROOT /home/cvs/groupfiles
  cvs checkout bibfiles

Alternately, you can run make -f /home/papers/makefile.bibfiles .

The files are checked out into bibfles/. You can then modify the files in this directory and run make checkin to update the files globally.

General CVS Points

  • Before you check in anything in, rebuild the proposal in your work space to ensure that it all still works. You don't want to check in a broken file and make life more difficult for others.
  • It is often faster to run your 'make's on a fast Linux box or other machine with good serial performance. Also, if your test builds are taking too long, you may want to build into local disk space instead of the shared file system.
  • Write good changelogs. It's well worth spending thirty seconds to document what you have done now, rather than spending hours later trying to work out when you made a fateful change...

Important CVS Commands

  • cvs checkout PROJECT - checks out the given PROJECT into a new directory.
  • cvs update - checks out any changes that have been made to the proposal since they were last downloaded. Should be done periodically.
  • cvs commit - actually upload your changes. If there are any conflicts, you will be prompted to resolve them; make sure you do this safely.
  • cvs add REPORTNAME filename - add a file to the CVS tree the next time you run cvs commit