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.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.
...
Here is the help output:
| Wiki Markup |
|---|
$ python tagCtntagCollector.py \-h Usage: tagCtntagCollector.py \[options\] container |
...
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.)
| No Format |
|---|
$ python tagCtntagCollector.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 |
...
- 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
An alternate approach is used in the RMViewer tag collector: it checks out the release and uses cvs tag rather than cvs rtag. This has the advantage that the files actually are there so one can use file system commands to learn things about the release rather than the rather awkward cvs rlog but there is presumably a performance disadvantage, especially for remote users.
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
...
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.