SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
Workbook HEPIC Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Wkbk. Search
Wkbk. Sitemap
Introduction
Non SLAC
HOWTO's
Introduction
Logging In
QuickTour
Detector
Info Resources
Software Infrastructure
CM2 Introduction
Unix
OO
SRT
Objectivity
Event Store
Framework
Beta
Modifying Code
Writing and Editing
Compiling
Debugging
Analysis
Framework II
Analysis
Find Data
Batch Processing
PAW
PAW II
ROOT I
ROOT II
ROOT III
Advanced Infrastructure
New Releases
Workdir
Main Packages
Event Displays
Gen/Sim/Reco
Contributing Software
SRT and CVS
Coding
Advanced Topics
Make CM2 Ntuples
New Packages
New Packages 2
Persistent Classes
Java
Site Installation
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

Workbook for BaBar Offline Users - SRT and CVS Background for Software Contributors

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 Tools first.

Contents


Working with the Package Coordinator

Contact your Package Coordinator before doing anything with an existing BaBar package.

Related Documents:


Managing an Existing Package using CVS - Committing New Code to the Repository

What one needs to know to write and modify code without screwing up the repository. CVS is 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 Jan2006):
Tags of two sampled files:
1. /afs/slac.stanford.edu/g/babar/repo/EmcCalPi0/GNUmakefile,v:
        V00-08-00:1.13
        V00-07-03:1.13
        jst01072005:1.13
        V00-07-02:1.13
        V00-07-01:1.13
        V00-07-00:1.13
        V00-06-00:1.13
        V00-05-12:1.13
        V00-05-11:1.13
        V00-05-10:1.13
        V00-05-09:1.13
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.
Here is 
'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 the package.
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 official release.

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
less Tag
to find the version number.

Related Documents:


Tagging Conventions


Dealing with Objectivity through gmake Commands

The phony package "database" and its gmake targets.

Related Documents:


Back to Workbook Front Page

Joseph Perl
John Bartelt
Jenny Williams

Last modification: 20 January 2006
Last significant update: 4 July 2001