...
Script tagCollector.py has been committed to CVS (grits-tools/python/tagCollector.py). This page has been updated for version 1.9.
Functionality
To start, will just handle the most common activities:
...
In this version PARENT can only be HEAD. In order to set the FORREAL or VERBOSE options to True, you must type the entire word, e.g.
| Code Block |
|---|
$ python tagCollector.py --new=HEAD --verbose=True
|
Here is a sample upgrade file:
...
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.
containerNotes.txt
If the container has a file containerNotes.txt at the top level, as of version 1.9 (committed to CVS March 10, 2011) the tagCollector script will give it some special handling for HEAD tags: the most recently committed version of containerNotes.txt will get the new HEAD tag. (The file isn't required; if it doesn't exist, tagCollector will put out an informational message but will keep going.) The intent is to give the owner of the container a place to document the contents of the new HEAD. There are no constraints on the file, but it is probably most useful as a log (new information is appended or inserted; old entries are left alone) containing at a mininum the name or user id of whoever is making the new tag and a timestamp. When creating release tags, tagCollector treats containerNotes.txt just like everything else: everything with the most recent HEAD tag will also get the new release tag.
Still To Do
- test adequately Creating next HEAD tag has been tested for Toy-scons, a DONE Testing deemed adequate as of March 10, 2011.
- 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. DONE The file is called packageList.txt.
- add ability to make release tags along a branch
...
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.