Anonymous versions in a merge tree
Geoffrey Clemm (30.1k●3●30●35)
| asked Aug 07 '09, 11:02 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I got the following question via email:
I did a standard merge, so there are 4 versions involved - the OK, this is a tricky one. While a change set is open, you can checkin the same file multiple times to that change set. Currently, the history viewer only shows you the result of the last checkin to a file ... not any of the intermediate checkins. So what happened here is that you created the second contributor and then did the merge in the same change set. This means that the second contributor is an intermediate version, and cannot be viewed in the history view (or for that matter, in any other view that I'm aware of). I seem to recall this problem being reported before, but I can't find the work item for it, so I've submitted defect 89503 for this problem. I also can't find any way to compare non-successive versions. Happily, there is an easy answer to this one ... just select the two rows for the two versions you want to select (control left-click, so that you don't select all the rows between the two rows). Then right-click on one of the selected rows, and you'll have a "Compare" operation, which will compare those two selected versions. This is one of these "obvious once you know it" tricks (:-). Cheers, Geoff |
One answer
The doc says: "Intermediate versions, such as changes that were checked in between the two states, cannot be retrieved from a change set."
Does this mean that even when the change set is open, the developer can't get at intermediate versions - say, the version he created at 18:00, before he put in 3 hours of overtime and screwed up things royally because he was too tired to work productively? This doesn't seem right. The point of checking in is to be able to get at something again. I saw some of the traffic in 89503. Let me make some suggestions, based on experience with ClearCase. 1) While an activity is underway, the developer wants to be free to check in at will and get at previous versions, but when the activity is finished the intermediate versions are of little value and only the last really counts. This is true, except for "significant" versions. 2) The only significant versions I see so far in RTC are those that contribute to merges; there may be others. (Can you put a baseline on an intermediate version? I think I saw that the changeset was automatically closed when I created a baseline.) 3) The developer should be free to delete insignificant versions (cleartool rmver) both while the changeset is open and when it is closed. 4) There should be a prompt to delete insignificant versions when a changeset is closed - or maybe this should be the default and the developer can override it. This prevents the history from getting clogged up with uninteresting versions, a typical problem in CC, and is also good for minimizing storage requirements for binary files (e.g. documents), since versions can't be delta'd. 5) The history view should show significant versions and should have an option to show insignificant versions. Directly from the view it should be possible to delete one, several or all insignificant versions. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.