...
The procedure for creating a new HEAD tag is more complicated because the caller specifies packages to be addeed, removed or upgraded. It includes the following steps:
...
, but it also involves adding a tag "all at once" to a collection of files which already have some other tag.
Options for Improvement
- Leave procedures as they are. Work on automating detection and possibly repair of stale CVS locks and incomplete tags.
- Modify creation of HEAD and release tags to go package by package. The description of a HEAD or release tag is based on a list of package tags; the tag itself is then a derived quantity. The primary source for the list of package tags may be
- in a file, e.g. packageList.txt OR
- in the RM database
- Get rid of container-wide tags altogether, at least for HEAD and releases. For container check-out, write script which can interpret list of package tags (in form of file or db entries) belonging to the build and check out files accordingly. Would also need a new trigger for RM to build the new HEAD or release tag.
My preference is for some form of 2. 1. doesn't attempt to address the root of the problem. 3. involves possibly significant changes to RM operation (but I defer to Tom as to whether this is a real concern).
LATEST tags appear to be much less subject to problems than HEAD. I suspect this is because the LATEST tags are made bit by bit. At the very least, the SConsFiles part of each container should receive its (HEAD or release) tag last since RM is watching SConstruct to determine when there is a new tag to be built.
2.b. is probably more robust but also more work since the tagging entity (new incarnation of tagCollector.py or revised RMViewer) has to access the database
...
.