...
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 ?
...
I remember to hear often people (toby, navid, richard ?) complaining about the <package>_ROOT variables generated by CMT. What is the reason for this ? There are too much variables declared by CMT ?
CMT and Windows
Several cases are under investigation :
- Does CMT support new Visual Studio (2005 or v8) ? Or is it planned ?
- Is there a way to switch off the generation of Visual Studio files by CMT ?
- Where are stored the temporary files (which are used to trigger the cmtcvs pluggin) and how to customize this ?
CMT Is Too Coarse
From Joanne Bogart
...
... for example, I see a package as an atomic object in CMT design .. I think that if in the same package two constituents uses different dependenecies, this is not CMT problem but point to a need of reorganization of the packages, maybe these two constituents should not really belong to the same package (but again, I'm not an expert on this, so maybe I'm completely wrong)...
From David Chamont
I also heard about problems with the huge number of useless libraries which
are propagated to the final applications. The art of "no auto_import" can
help us to reduce the problem, but not easy enough (see FluxSvc).
...