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
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
-n NEWTAG, --new=NEWTAG
HEAD or specific tag to create
-u UPGRADEFILE, --upgrade_list=UPGRADEFILE
File listing packages to upgrade, add or remove
[default: upgrade.txt]
-r FORREAL, --for_real=FORREAL
Really do it or just print what we *would* do
[default: False]
-v VERBOSE, --verbose=VERBOSE
Show all cvs command output if true [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.)
$ 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-tmphead824 ScienceTools-scons Just fooling; it wasn't for real about to issue command cvs rtag -d ScienceTools-tmphead824 facilities Just fooling; it wasn't for real about to issue command cvs rtag -r facilities-02-19-02 ScienceTools-tmphead824 facilities Just fooling; it wasn't for real about to issue command cvs rtag -d ScienceTools-tmphead824 sourcelike Just fooling; it wasn't for real about to issue command cvs rtag -r xmlUtil-03-04-01 ScienceTools-tmphead824 xmlUtil Just fooling; it wasn't for real about to issue command cvs rtag -r ScienceTools-tmphead824 HEAD-1-824 ScienceTools-scons Just fooling; it wasn't for real about to issue command cvs rtag -d ScienceTools-tmphead824 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.
- make a new tag with the official name (next HEAD) from the temp tag; remove the temp tag
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.
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, 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.