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
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.
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
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.
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.
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.
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.
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.
Page maintained by Adam Edwards
Last modified: January 2008
| 