SLAC PEP-II
BABAR
SLACRAL
Babar logo
SPIRES E S & H Databases PDG arXiv
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Home
Workbook
 1. Introduction
 2. Accnt. Setup
 3. QuickTour
 4. Packages
 5. Modules
 6. Event Info.
 7. Tcl Cmds.
 8. Editing
 9. Comp.+Link
 10. Run the Job
 11. Debugging
 12. Parameters
 13. Tcl Files
 14. Find Data
 15. Batch
 16. Analysis
 17. ROOT I
Additional Info.
 Other Resources
 BABAR
 Unix
 C++
 SRT/CVS Cmds.
 SRT/CVS Dev.
 Sim/Reco
 CM2 NTuples
 Root II, III
 PAW I, II
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator

(More checks...)

Useful SRT and CVS Commands



In the Packages and Releases section of the workbook, you learned about the most important SRT commands: newrel, addpkg, and srtpath. This section lists and describes additional SRT/CVS commands useful for keeping track of your code changes, and updating packages and releases. It also includes a list of commands used to keep track of the tags in your test release.

Note that many of the commands described below will not work unless you have issued the srtpath command from your test release.


Commands for editing and tracking code changes

Searching BaBar code: srtglimpse

A very useful SRT command to use when in a release (after typing "srtpath") is

srtglimpse [expr]

where [expr] is any expression (e.g. a word, such as "SoftRelTools" or "histogram"). This searches for the expression in all subdirectories in the parent directory of your release (including those packages you haven't even checked out!). This can be extremely useful when trying to unravel dependencies of various packages, or just to learn how to use a particular expression.

Seeing what you changed: cvs diff

It is often useful to check what you have changed. You can do this with:

gt; cvs diff

This command will then list all the differences between your code and the version that you originally checked out. Variants:

package> cvs diff
      OR
test-release> cvs diff Package
Shows you the difference between your (edited) package and the original package in $BFDIST with the same tag.
test release> cvs diff

Applies "cvs diff" to each package in the test release.

package> cvs diff File

Diffs only that one File in package.

Try it for yourself!:

ana30/BetaMiniUser> cvs diff
ana30> cvs diff BetaMiniUser      # same output
ana30> cvs diff                   # diffs BetaMiniUser and workdir
ana30/BetaMiniUser> cvs diff AppUserBuildBase.cc   # diffs AppUserBuildBase.cc only

Updating packages and releases

If you are doing an analysis over an extended period of time (more than a few months or so), you may find that BaBar software has been updated and improved since you began your analysis. As bugs are discovered in current packages, new bug-free packages are created to fix the bugs. And every few months or so, the current recommended release is replaced by a new one.

Often it is best to stick with your older release. Much of your analysis has already been done using that release, and you know that the code is self-consistent and stable. On the other hand, modifications that you have made in your old package or release might not work in a newer package or release.

However, sometimes it really is necessary to update to a new package or release. Perhaps the newest data is compatible only with a newer release than you are using. Or perhaps you have been advised by either the Extra Tags webpage or by an expert to update.

For this situation, SRT provides a set of commands for updating or deleting packages and releases. This section will describe these commands and how to use them. But first, it will cover some useful commands for keeping track of changes that you have made to your code, so that you can catch potential conflicts before you run SRT's update commands.


Updating a package: cvs update

The basic command to update a package is (from the package directory):

Package> cvs [-n] update -r <new_tag>

You will want to use this command twice: once with the -n option, and once without.

The first time you use cvs update, you should use the [-n] option to find out what the update command will do:

Package> cvs -n update -r <new_tag>

With the -n option, cvs does NOT change any files. Instead, it tells you what it WOULD do if you issued the command without the -n option. If the proposed changes are acceptable, then you can issue the command without the [-n] option:

Package> cvs update -r <new_tag>

In response to this command, cvs will try to update your package to the new tag. As it does so, it will try to merge any changes you may have made to the package, so that the changes you have made will not be lost.

Sometimes it happens that changes that have taken place between the different tagged versions and changes that you have made yourself occur at the same place and cvs can't merge them to its satisfaction. In this case it will report a conflict and not update the files it finds conflicts in, leaving it to you to sort out the problems yourself before the update can be completed.

For this reason, you are advised to use the statusrel -rf, cvs diff, and cvs -n commands to check for potential conflicts before you run cvs update.

Updating to a more recent release: updrel

If you already have a release and a number of associated packages checked out and wish to update to a newer (or older) release, the command you need is updrel. The syntax is (from your test release):
test-release> updrel <new-release-number>

The updrel command will update the checked-out packages for to the tags of the new release. In other words, updrel applies "cvs update -r TAG" to each package, where TAG is the tag of the package associated with that release.

Warning: The command does try to merge any changes you have made with the release version of the packages. But it may not always succeed. Also beware that all the individual packages that you have checked out will be "updated" to the tags associated with your new release - even if the current tags you have checked out are newer than those tags from the new release! If you have made significant changes in the code, or if your release is very much older than the release you want to update to, then it may be safer to just set up a new release from scratch.

Deleting packages: delpkg

Sometimes you may wish to entirely remove an individual package that you have checked out. This is usually either because you have checked it out and then found you didn't need to change it, or the use you made of the package is now finished and you wish to use the standard build. If you remove a package, your future analysis jobs will revert to the default version of that package for your release (the version in workdir/PARENT).

The SRT command to remove a package is delpkg. Unlike "rm -r" (NOT recommended), the delpkg command removes the package and also ensures that all associated library and binary files get removed.

test-release> delpkg <package_name>
You have to answer "yes" after a few seconds to confirm removal of the package.

Keeping track of tags

showtag

When issued from a release, showtag lists the version tags for every package in the release. When issued from a package, shows the version tag for that package. For example:

ana31> showtag

BetaMiniUser V00-04-00
workdir V00-04-20

srtlsttag

If you want to know which tag is in a release for a specific package, you can type

srtlstag <release> <package>
For example, following the analysis in the quicktour:
ana31> srtlstag 12.3.1 workdir
You should see:
workdir V00-04-10 12.3.1
This means that the workdir tag for release 12.3.1 is V00-04-10. This is different from your workdir tag V00-04-20, which is the one that belongs to analysis-31.

statusrel

The statusrel command lists the package tags in a test release, and compares them to the package tags in the base release. The command is issued from your test release. The syntax is:
statusrel [-t] <release> [<pkg>]

For each package contained with a release, statusrel prints to standard output the package name, the version number of the package used, and (if different from the version used) the tag of the most recent available version.

The command-line option, -t, stands for test release. This tells statusrel that the current directory is a test release based on <release>. It also prints the tag in <release>, if different from the version used. For example, in the Quicktour you could have entered:

ana31> statusrel -t analysis-31

statusrel version: 1.5
Treating current directory as a test release based on analysis-31
BetaMiniUser  V00-04-00  (Release uses V00-04-00)
workdir  V00-04-20  (Release uses V00-04-20)   (V00-04-21 more recent in $BFDIST/packages)

The workdir package has been updated since analysis-31, hence the "VXXX more recent in $BFDIST/packages" comments.

For other command-line options check out the man page for statusrel.

cvs status

1. It is often useful to list all tags for a particular package file in chronological order. This is done by
cd <package>
cvs status -v <file>
To stop the output from flying by before you can see it, pipe the command to "less":
cvs status -v <file> | less
(Once you are done viewing the output, press "q" to exit from "less".)

listtag

Listtag lists all the tags of a package that exist. The syntax is:

> listtag <package>

Note that the list includes "unofficial" tags that are not recommended for use in analysis.


[Workbook Author List] [Old Workbook] [BaBar Physics Book]

Valid HTML 4.01! Page maintained by Adam Edwards

Last modified: January 2008