Status
Script tagCollector.py has been committed to CVS (grits-tools/python/tagCollector.py).
Functionality
To start, will just handle the most common activities:
- Make a new release tag which is identical to current HEAD build
- Make a new HEAD by changing some package tags, adding new packages or removing packages as compared to current HEAD
If a file packageList.txt, listing all packages and versions in "this" build, exists at the top level (e.g. ScienceTools-scons/packageList.txt) tagCollector.py will update it appropriately.
At some point would like to add ability to make a new tag along a branch by updating, adding or removing packages relative to an existing tag on that branch.
Call Interface, Usage
Here is the help output:
$ python tagCollector.py -h
Usage: tagCollector.py [options] container
Options:
-h, --help show this help message and exit
-p PARENT, --parent=PARENT
HEAD or (branched) release tag to act as base
[default: HEAD]
-n NEWTAG, --new=NEWTAG
HEAD or specific tag to create; required option
-u UPGRADEFILE, --upgrade_list=UPGRADEFILE
File listing packages to upgrade, add or remove; used
only when creating a new HEAD [default: upgrade.txt]
-r FORREAL, --for_real=FORREAL
Really do it or just print what we *would* do
[default: False]
-v VERBOSE, --verbose=VERBOSE
If True show all cvs command output and do not delete
temp files or tags [default: False]
In this version PARENT can only be HEAD.
Here is a sample upgrade file:
#a comment // another sort of comment u facilities facilities-02-19-02 r sourcelike a xmlUtil xmlUtil-03-04-01
and here is output when it was used as the value for upgrade_list. (This is output from an old version. The version in CVS does more and says more, mostly having to do with maintenance of a file packageList.txt.)
$ python tagCollector.py ScienceTools --new=HEAD tagCtn was invoked with argument ScienceTools and options parent= HEAD new= HEAD upgrade_list= upgrade.txt for_real= False verbose= False about to issue command cvs rlog -b ScienceTools-scons/SConstruct lastHeadTag is: ScienceTools-HEAD-1-823 about to issue command cvs rtag -r ScienceTools-HEAD-1-823 ScienceTools-HEADTMP-1-824 ScienceTools-scons Just fooling; it wasn't for real about to issue command cvs rtag -d ScienceTools-HEADTMP-1-824 facilities Just fooling; it wasn't for real about to issue command cvs rtag -r facilities-02-19-02 ScienceTools-HEADTMP-1-824 facilities Just fooling; it wasn't for real about to issue command cvs rtag -d ScienceTools-HEADTMP-1-824 sourcelike Just fooling; it wasn't for real about to issue command cvs rtag -r xmlUtil-03-04-01 ScienceTools-HEADTMP-1-824 xmlUtil Just fooling; it wasn't for real about to issue command cvs rtag -r ScienceTools-HEADTMP-1-824 HEAD-1-824 ScienceTools-scons Just fooling; it wasn't for real about to issue command cvs rtag -d ScienceTools-HEADTMP-1-824 ScienceTools-scons Just fooling; it wasn't for real
If the value of for_real had been True, the cvs commands appearing in the output all would have been executed. Since it was False for this run, the only cvs command which actually was executed was the first one (cvs rlog ..) since it's a read-only command which does not affect the repository.
The overall strategy in the make-new-HEAD case shown above is
- make a temporary tag which is identical to the most recent HEAD tag
- if a package is to be added, issue a cvs rtag command to tag it with the temp tag
- if a package is to be updated, first remove the temp tag from the module, then add it to the specifed package tag version.
- if the file packageList.txt exists in the container's top-level directory, check it out, update to reflect tags to be used in new version, commit and tag with the temp tag.
- make a new tag with the official name (next HEAD) from the temp tag; remove the temp tag and temporary directory where packageList.txt was checked out.
The function to make a release tag from HEAD is much simpler: just issue a cvs command to make the new specified tag from all files bearing the latest HEAD tag.
packageList.txt
This file lists all packages comprising the container, somewhat analogous to the CMT requirements file for the container package. It is not normallly edited by hand. The file contains a series of lines of the form
<cvs-path-to-package> <tag>
e.g.,
flux flux-08-40-07
The file may also contain blank lines or comments (any line beginning with #), which are ignored.
The file is not used as input to the tagging operation, but it is updated to reflect the changes specified in the user's upgrade file, thereby providing a record of exactly which tags are in each head build or release tag.
Still To Do
- test adequately Creating next HEAD tag has been tested for Toy-scons, a
- add as output a file which lists all the packages and their tags belonging to the new tag just created. The file probably should go at the top level (e.g., in the ScienceTools-scons directory). One possibility in the new-HEAD case is to create it after the temp. tag has been made, submit to CVS, move temp tag to the new version, then make the final new HEAD tag. However, if we plan to also support tag collecting from RMViewer, it would have to go through a similar procedure.
- add ability to make release tags along a branch
Sticky Points
The way CVS tagging is currently set up (in particular, the script $CVSROOT/CVSROOT/tagger), you would have to be logged in as glast or glastrm to run the script in "for real" mode.
Proposal: Modify tagger script to allow creation and deletion of tmp tags with names satisfying a pattern. Should be something like HEAD pattern except replace HEAD with string HEADtmp, possibly HEADtmp<stuff> where <stuff> is an arbitrary and optional alphanumeric string if, e.g., we want to distinguish different attempts of creating HEAD of a particular version. DONE
Certain assumptions are hard-coded in the script when, ideally, they should come from the RM database: for example, which container packages are active and exact format of tags. These things don't change very fast, if at all, but if they do, someone will have to remember to update the script.