This section contains a brief synopsis of the major tools used in implementing this configuration management scheme, as well as a summary of the major usage or commands associated with each.

 

CVS

CVS is an acronym for Concurrent Versioning System, a tool designed to manage and track revisions of sets of documents. Documents managed by CVS may include source code, build files, project documentation, etc. All documents are contained in a central CVS ‘repository’, located on the slac.stanford.edu network node. There is a CVS server application which runs on the central repository node and communicates with the various CVS client applications used by the individual users.  There are some general concepts within CVS, which are worth discussing here.

Tracking Versions

The basic model for CVS is to keep a copy of a particular file at a single location – namely the repository. Such a file is then checked out by a user to some other location. Effectively this means that the file is copied into a working directory for the user by the CVS client application. Additionally, the CVS client application creates serveral files in the local directory which it uses to delineate the status of the files therein.  The user is then free to modify the file in their working directory.

Committing Files - Revisions

When a user is satisfied with the modifications to a file and is ready to make it part of the collaborative effort, they must commit the file to the repository. Here the CVS client will compare the file in the user’s working directory to the copy that exists on the server, log any differences, and copy the user’s copy of a file to the repository. The user’s version of the file then becomes the current revision of that file in the repository and is said to be at the HEAD of the repository. Each time that this occurs, the CVS server assigns a new revision number to the file. Other users may then overwrite the copies of the older revision which are sitting in their working directories (assuming they had done a check-out prior to the commit) by asking the CVS client to update the files in their working directory. In this case the CVS client fetches the new versions of any files that it finds both in the current working directory and in the CVS repository and replaces them in that user’s working directory.

Tagging

In order to specify a particular version of a file with a logical name, CVS supports a mechanism known as tagging. Here a name is associated with a particular revision of a file such that a user can ask the CVS server for a file revision associated with that name when checking out. In this mode, the CVS client records that it has taken a particular tagged version from the repository. When the user does an update for a file which has a tag associated with it, the client checks that the tagged version of the file in the user’s working directory points to the same revision of the file that the tag points to in the repository. If the revision numbers are different, the client attempts to update the file in the local user’s directory with the file revision associated with that tag in the central repository. Additionally, if the user attempts to commit a file that has a tag associated with it, the CVS client will not allow it. This is known as a sticky tag. Commits may only occur onto the head of the repository for a particular file. In order to add their changes to a particular file to the repository, the user must first remove the sticky tag from their local version of the file by updating it with the HEAD revision of that file from the repository. Then the user may commit their changes.

To check-out or update a file with a particular tag or revision from the repository, CVS provides the –r option, which fetches a specified tag or revision number, and the –A option (update only) which removes all sticky tags and gets the HEAD version of a file from the repository. For example:

cvs update –r v1 Filename.file

cvs checkout –r v1 ModuleName

cvs update –A Filename.file

 

Here, the first command will update Filename.file with the revision associated with the tag v1 in the repository. The second command will check-out the module ModuleName from the repository, each file being of the tagged version of the file within the repository. These first two commands will associate a sticky tag with the corresponding files in the user’s working directory, such that corresponding updates will check the files in the user’s working directory against the tagged revisions in the repository, rather than the HEAD revisions as is the default. The last command above updates the Filename.file in the user’s working directory with the HEAD revision of the file in the repository and dissociates the file with any sticky tags.  This tagging feature of CVS is mentioned here due to it’s heavy incorporation with the CMT architecture, which is discussed here.

Branches

What if one wants to work from a revision of a file which is no longer the head of the repository, without incorporating changes directly into the portion of the repository that everyone else is using? An excellent example of this is the work done to simulate the 1999/2000 beam test instrument. In that scenario, work was to continue on the general GLAST simulation, while some of the code needed to be modified specifically for the test-beam environment. In order to track the changes to the test-beam specific code separately from the changes to the general simulation code, a ‘testbeam’ branch of the CVS repository was made for those packages involved in simulating the test beam instrument geometry and response. This allowed concurrent development of the testbeam and general simulation codes.

The following links provide a much more detailed overview of how to use CVS:

http://sunsite.ualberta.ca/Documentation/Gnu/by-node/cvs-1.10.7/cvs/cvs_toc.html

The above link is to the main CVS support site (relatively new).

 


 

T. Lindner Last Modified: 12/02/2002 11:40