Workbook for BaBar Offline Users - SRT and CVS Background for
The developer's perspective on SRT, and what one needs to know to
write and modify code without screwing up the repository. New users
should read the introductory material about SRT and CVS in the
Workbook section SRT: the Software Release
Contact your Package
Coordinator before doing anything with an existing BaBar package.
What one needs to know to write and modify code without screwing up
the 'version control system' (or 'concurrent version system') that
ensures Babar has a consistent set of software packages. The Software
Release Tools section of the Workbook contains an introduction to
CVS. See also the introductory document entitled Basic
CVS commands used by BaBar. This section contains a summary of Frank Jackson's
experience in using CVS to update a package, EmcCalPi0.
After setting up a new release (see Quicktour) and checking out a
package that is to be modified, for example, EmcCalPi0:
addpkg -h EmcCalPi0
where -h refers to the 'head' or latest version, the package
can then be modified by the developer.
Note: You should avoid mixing files from different CVS
locations (e.g. SLAC and RAL).
Before you commit changes to the repository, it is often useful to
check what you have changed. You can do this with:
cvs diff <package name>
This command will then list all the differences between your code and
the version that you originally checked out. This is exactly the list
of changes that cvs will assume that you then want to commit.
Note that it is possible that in between checking out a file and
committing a new version that someone else checked in some changes,
CVS does not ``lock'' files which are checked out. CVS only provides
the tools to help manage the development of software, it does not do
the management. This is the responsibility of the package coordinator
and other developers.
Before committing changes, one must do:
EmcCalPi0> cvs -n update -A
The '-n' ensures that no changes are made to the local copy, but
checks the consistency between the latest version of the package at
the repository and the local version that you have been
modifying. This will inform you of any changes and any conflicts
between the latest version (the cvs 'head') of that package, held in
the 'cvs repository' and the package that you have in your release
directory. The '-A' shows changes that have been made by others since
you checked out your copy of the code - this provides a good way to
check for potential conflicts.
If you issue the command
EmcCalPi0> cvs update -A
cvs tries to update that package in your release directory with the
changes in the latest version of that package. If there are any
conflicts between the head and your version, you will need to resolve
them. Once this is done, a cvs update -A command will 'merge'
your version with the head. This means that you will have the latest
version with all the recent changes, including your own, and are now
ready to commit the updated package to the repository.
*Note* if you have added new files to the package
you must do a
cvs add <filename>
For each new file to have it scheduled to be added with the next
commit call to CVS. Similarly, if you wish to remove
files from a package, you need to do
cvs rm <filename>
to schedule the unwanted file for removal (simply deleting the file
from your checked-out release will lead to the file being replaced by
CVS when you next update).
To commit your files, do
EmcCalPi0> cvs commit
An emacs window will appear where you should clearly detail
your changes, the contents of this will be sent to at least the
package coordinator and possibly to others too. After you have
described your changes, save the file and exit the emacs session with:
Ctrl-X Ctrl-S, Ctrl-X Ctrl-C
To tag the new version of the package, first do
> listtag EmcCalPi0
You will see an output like (note the tags shown here are from
Tags of two sampled files:
In this case, EmcCalPi0 V00-08-00 is the latest
version, so your tag should be V00-08-01.
PLEASE CONTACT THE PACKAGE COORDINATOR BEFORE TRYING TO CREATE A NEW TAG.
In most cases, it's the package coordinator who creates a new tag, after
collecting submissions from different Babarians.
'List of Package Coordinators'
To tag a new version, enter:
EmcCalPi0> cvs tag [version number]
The final step in commiting a new version of a package is to go to the
Hypernews forum `package release announcements'. Click on New Package Version
Announcement Form and then on check list to fill out a
form before submitting the hypernews e-mail.
You will be asked if you have tested your package on Sun and Linux
To compile on Linux, ssh yakut or noric,
go to the top of your test release which contains your package,
srtpath to set BFARCH to Linux-blah, then gmake installdirs
to set up lib, bin, etc links for the new architecture, and compile
If you originally compiled your code on a Linux machine, you will
need to log into a Sun machine such as tersk or
shire and follow the procedure for Linux.
After this is done the package should go into the `nightly' release
but not the next `official' release, for this to happen a request must
be made to the person in charge of packages and tags for the next
To check if your version of the package EmcCalPi0 has gone into a
particular release, change directory with
cd $BFDIST/releases/[release no.]/EmcCalPi0/CVS
and then do
to find the version number.
The phony package "database" and its gmake targets.
Last modification: 20 January 2006
Last significant update: 4 July 2001