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.
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.
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 users working directory to the copy that exists
on the server, log any differences, and copy the users copy of a file to the
repository. The users 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 users working directory.
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 users 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 users
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 users working
directory, such that corresponding updates will check the files in the users
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
users 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 its heavy
incorporation with the CMT architecture, which is discussed here.
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