CVS on Darwin

By Jim Ries

 

CVS (Concurrent Versions System) is an open source version control system for Unix and Unix-like platforms.  CVS is the version control system of choice for projects hosted on darwin.rnet.missouri.edu, including the Monsanto Swine Genomics Project.  A complete CVS manual is available.

 

Motivation

CVS is extremely useful when multiple developers want to work together on a project.  It allows developers to easily keep up to date with the latest changes, and also to make "local" or "test" changes without causing problems for others.

 

Setup

Local CVS use on Darwin

You must setup your environment as follows when logged in to Darwin for using CVS:

  1. The cvs executable is in /usr/local/bin.  You should not have to modify your path to access it..
  2. You must have the CVSROOT environment variable set to the repository used by the project on which you are working.  For the Monsanto Swine Genomics project, it should be CVSROOT=/evbio/Swine/src/cvsroot

Remote CVS use of Darwin's repositories

If you wish to use CVS on a remote platform (e.g., a Windows-based PC) to access a repository which is stored on Darwin, you should setup your environment as follows:

  1. CVSROOT=:ext:username@darwin.rnet.missouri.edu:project_path. 
    For example, a user with an id "ries" working on the Monsanto Swine Genomics project would have this set to:
    CVSROOT=:ext:ries@darwin.rnet.missouri.edu:/evbio/Swine/src/cvsroot
  2. CVS_RSH=ssh_client_name
    For example, ssh_client_name is typically ssh under Unix or ssh.exe under Window. Since Darwin must be accessed securely from the network, ssh is required as opposed to rsh. A command-line secure shell for Windows PC's is available. I built a binary version of this secure shell, available here.  The scp command is also available for Win32, and my built version is here.
    For either ssh or scp, you will need these dll's in your path: gmp.dll and zlib.dll.
  3. CVS_SERVER=/usr/local/bin/cvs
  4. CVSEDITOR=editor_name (optional) This environment variable controls the editor one uses to enter comments when checking revisions into CVS. By default the vi editor is used. On Windows, one may wish to set this to Notepad.exe, e.g.:
    CVSEDITOR=notepad.exe
  5. You need to have the Win32 version of CVS on your path.  Here is my build of Win32 CVS.

Summary of Win32 CVS-related resources available for download

cvs.exe, ssh.exe, scp.exe, ssh-keygen.exe, gmp.dll, zlib.dll.

Note:  If you wish to use CVS on another remote platform (e.g., RedHat Linux) and would like to build the executables, I would be happy to include them here for others to download.  Just send the results to JimR@acm.org.

 

Basic Scenario

CVS allows one to "checkout" from and "commit" files to a shared repository.  The repository is essentially a library containing the current revision and all previous revisions of various source (and possibly binary) files.  Normally, several developers will setup projects on which they will all be working and then "checkout" working copies of those projects.  Each developer will make changes to their local versions of the projects and will then "commit" those changes to the repository.  Periodically, developers will update (also via the "checkout" facility) their local projects to incorporate changes the other developers have made.

Example 1 - Normal work

Arturo and Jim are working on a project called "coolstuff".  Arturo checks out a copy of the project to his working directory on darwin, edits a file, and commits his change:

  1. cvs checkout coolstuff

  2. cd coolstuff

  3. vi my.c

  4. cd ..

  5. cvs commit coolstuff

Jim has a copy of coolstuff on his local PC.  Jim is changing another file.

  1. cd coolstuff

  2. vi somethingelse.c

  3. cd ..

  4. cvs commit coolstuff

When Jim is finished, he decides to get everything up-to-date

  1. cvs checkout coolstuff

At this point, Jim notices that new changes to my.c have come in from Arturo.  Since CVS is file-based, it is POSSIBLE that changes to somethingelse.c are now incompatible with the change from Arturo to my.c.  However, this is not typically the case and can generally be avoided by employing good design techniques.

If Jim and Arturo had made changes to the same file, CVS would have attempted to merge these changes when a commit was done.  Most often, CVS can successfully merge changes, but it will report an error and give additional information if it cannot merge changes (e.g., one party has deleted a function while another has modified the same function).

Example 2 - Adding files to an existing project

To add files to the coolstuff project

  1. cd coolstuff

  2. cvs add added1.c

  3. cvs add added2.c

  4. cd ..

  5. cvs commit coolstuff

Example 3 - Creating a new project

This one is a little confusing.  It uses the "import" command.  To create the new project called "coolstuff":

  1. Go to the coolstuff directory

  2. cvs import coolstuff vendortag releasetag

  3. cd ..

  4. mv coolstuff coolstuff.bak

  5. cvs checkout coolstuff

  6. Compare coolstuff and coolstuff.bak to be certain all went as expected.

  7. rm -r coolstuff.bak

The vendortag and releasetag aren't particularly useful as far as I can tell.  I use "JimR" as the vendortag and "initial" as the releasetag.