Status
I've written a first attempt (tagCtn.py) which seems to operate as intended, but so far has only been tested in a dummy mode where it only says what it will do without actually creating or modifying any tags in CVS.
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
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 tagCtn.py -h
Usage: tagCtn.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, tags [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:
$ python tagCtn.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
- add ability to make release tags along a branch
- 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 (information would come from parsing output of a suitable cvs rlog command or commands) 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.
Sticky Point
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.