...
From D.Chamont
The "cmt cvstags <package>" command is used in several key places :
- We suspect CMT itself uses this to determine a version-folder name to use for the "cmt co" command, when a specific version is not specified.
- MRvcmt uses it to form a list for the pull down menu in the checkout dialog.
- The Release Manager use the first tag as the one to be used so to build LATEST.
- Some other developers (Jim) use it to trace the packages tagging.
here and there, usually to know about the last CVS tag of a package. On top of few bugs, there is much confusion about what should be the "last" tag,
and what is the ordering of tags when displayed by "cmt cvstags".
Have a look at https://confluence.slac.stanford.edu/display/core/Tagging+Information.
thsi command. This is what the CMT team expect the pluggin to do :
- The first tag, internally called the top tag, should be the one which has the higher CVS revision number. I also feel the tags on branches should not be eligibles, but I am not sure this is what the authors wanted. If so, this does not work.
- The following tags comes in chronological order, as they appear in file "<package>/cmt/requirements,v" . I feel the authors tried to filter out the branch tags, again without success, at least for repositories where the branch revision number contains an additionnal magic 0 just before the end.
After some unsatisfying debate with CMT team, where I did not succeed to understand what the pluggin was meant to do, I found no way to avoid a direct modification of the pluggin, and did the following :
- Modification of function check_newer() so that the selection of the top tag ignore the tags on CVS branches.
- Modification of the function getting the list of all tags, so that branch tags are ignored.
Until now, I do not want to prevent users from setting their own private tags, and yet take profit of "cmt co -R", so I didid modified the pluggin so to filter out whatever is not an official GLAST tag (v* or v*r* or v*r*p*). The tools such as the Release Manager still have to do this filtering by themselvesAbout the eventual modification of the cmtcvs pluggin,
I would not filter all the tags which are returned, because it
would break the recursive check-out for some developers which
are using exotic tags for their private use.
On the other hand, I could perhaps make everyone happy if
I convince the CMT developers that the pluggin should consider
only the trunk tags when searching for the top tag. On top of that,
we could add our own collaboration-specific filtering (v*r*p*), either
in the pluggin or in each collaboration specific tool (Release
Manager, developers scripts).
Installation Area
Can somebody explain why this CMT feature has been discarded ?
...