Using the CVS repository [email protected]

Important: This page has been modified to reflect the migration of the repository from vnfe4.physics.ubc.ca to bh1.physics.ubc.ca

Please report all errors/typos. etc to Matt Choptuik at [email protected]

Last updated May 24, 2012

IP Numbers

Public keys for ssh

Environment Variables

bash

Note the use of backquotes (not forward quotes) in the second environment variable assignment.

tcsh

Note the use of backquotes (not forward quotes) in the second environment variable assignment.

Checking Out (co) and Updating (update) Distribution

How you wish to manage the directories/folders that are stored via cvs@vnfe4 is totally up to you of course.  You might, for example, have a top level directory, ~/.projects, which would be a good place within which to check out a distribution.  So let's proceed on the assumption that you have a ~/projects (or equivalent!).  Then, to check out nmci from cvs@vnfe4, ensure that the two environment variables documented above are set properly, and
Note that if you and your colleagues use cvs properly then, in theory, you must only check out the repository once.  Thereafter one uses the cvs update subcommand to bring any part of the directory hierarchy (including the entire hierarchy) into sync with the master repository.
Note that the -d flag to the cvs update command tells CVS to update subdirectories recursively.  It is a common mistake not to include this flag and thus, if new files have been added in new sub-directories, not getting a completely up to date version of the directory.

Changing a Distribution and Commiting (commit) Changes

So far, the cvs commands that we have discussed suffice to have you "follow along" the development of a directory that is checked into cvs.  In computer parlance we have used our read access to the repository, but not our write access.  Taking advantange of write access (i.e. actively participating in the directory development, including any and all of the files defined within the directory) entails more responsibility of course,  but basically it suffices to abide by three (3) principles:
  1. Use another form of communication, probably electonic, ideally e-mail, to ensure that no two (or more!) people are simultaneously modifiying the same document at the same time.  If this really becomes necessary, break the document into separate pieces that the separate parties can work on.  In practice, provided one is diligent about e-mail with collaborators, little splitting is needed.
  2. Make changes carefully, test them if possible, then commit the changes as soon as possible.
  3. Make changes carefully, test them if possible, then commit the changes as soon as possible.
Example
I decide I'm going to hack on the Makefile for a bit, so I first ensure that my local copy of the nmci directory is up to date:
 I then invoke my favorite Unix editor on Makefile (you can guess which one that is!)
and ... hack, hack, hack, ... on Makefile I finish my changes, exit vi.  I now test the changes verify all is well, and/or modify Makefile as needed, re-test etc.  

Satisfied that I have correctly modified Makefile, I commit the changes, using a null message (-m ""), since messages aren't of much use if you don't routinely roll back changes, which we don't
Now, the last detail.  You will eventually probably want/need to add new (sub-)directories and files to the directory (repository).

To do that, use cvs add, followed by cvs commit. 

For example, here's how I added a couple of the elements of ncmi.
Let Matt know if you have questions about this, or should you encounter problems using [email protected], and particularly if you find errors in the above discussion!