CVS Cheat Sheet - CS 519, September 1998

CVS is a third-generation source revision control system.  It allows you
to save all versions of your software while minimizing diskspace because
it saves only one complete copy of the source, plus incremental updates.

Unlike RCS (the second generation system, which actually underlies CVS),
multiple parties can work on the same source file without locking it first.
That is because CVS takes care of merging multiple changes and tells you
about unsolvable conflicts (which then you have to work out yourself).

Here is the principle thing to remember: the "real" source code lives in
a repository that you never change.  Instead you check things in and out
of the repository.  You do actual editing, file deletions, and file creations
in your own working directory.  

Finally, CVS is very recursive.  In general, you will want to run your
update and commit commands from the top level in your working directory. 
CVS will then examine each file in that directory, plus files in any
subdirectory.  On the other hand, file-specific commands like add and delete 
could be done from the directory containing the file.

1.  Management Instructions (all teams should read)

 - Decide on a directory that is going to be your group's source repository
   and announce the full pathname to everyone in your group, e.g. "our
   repository will be /fsys/babbage/a/cs519mia/projectcvs/".

 - Everybody in the group needs to update their .cshrc or equivalent
   startup file to set CVSROOT to this directory, e.g.
       setenv CVSROOT /fsys/babbage/a/cs519mia/projectcvs

 - Somebody on the management team must then set up the initial repository:
    
   cvsinit      -- your $CVSROOT must be defined when you run this command
		   It sets up the $CVSROOT directory (creates it if not
		   there yet) with a CVSROOT/ subdirectory.  This subdirectory
		   contains administrative files that you should not edit!

 - Now set up sub-repositories for each team or let them do it for themselves.
   For example, if the sub-repository for Team 1 should be named "t1", then do 
   the following command:

   mkdir $CVSROOT/t1  -- make sure it is group readable-writable

In general the management team should also consider "gating" project software
periodically.  This means you ask everybody to "commit" their code (see
below).  Even better, arrange to test the gated system.

2.  Team Instructions

[ Starting with an empty working directory ]

   cvs co t1    -- or whatever your team repository name is (see mgmt)
		   This initializes ./t1/CVS/ for you.  Don't edit it!
   cd t1        -- Go into your newly initialized working directory
    :              Make some initial sources 
   
   cvs add mumble.java  -- schedule each new source for inclusion in repository
    :

   cvs commit -m'log message describing this update'  -- update real repository


[ Normal working procedure - you are in your working directory ]

 - Edit sources as needed.  If you create new files, do a "cvs add"
   command to schedule its addition.  If you want to delete some files,
   erase them from your working directory and schedule their deletion
   from the repository by doing a "cvs delete" command.  
   
 - Periodically incorporate new stuff that your team-mate[s] might have 
   put into the repository:

   cvs update   
   
   You are notified of conflicts, e.g. your partner committed something to 
   the repository which conflicts with some changes you made since your last 
   commit, you will have to get together and work out a compromise.  CVS will 
   take care of merging differences that don't conflict.

 - When it is time to do so, permanently update the repository:

   cvs commit -m'informative log message' 

   All of your changes go into the repository.  If you need to do an update 
   on some file, you are told to do this.  Do the update; if there is a 
   conflict, work it out with your teammate; then do a commit again.

   Repeat this sequence of 3 steps until the project is done.