It's all about the answers!

Ask a question

Anonymous versions in a merge tree

Geoffrey Clemm (29.7k23035) | asked Aug 07 '09, 11:02 a.m.
I got the following question via email:

I did a standard merge, so there are 4 versions involved - the
original parent (3rd row), the result (1st row) and the two
contributors (2nd row). I did this by changing the file in parallel
in two workspaces attached to the same stream, delivering from one
and accepting in the other.

I can't find any way in this view to do a compare of the result with
the 2nd contributor. I guess this is the one on the right, where
there is no square, which I also don't undersand - why no square?

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 (:-).


One answer

permanent link
David Sedlock (16111912) | answered Aug 10 '09, 11:08 a.m.
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

Register or to post your answer.