Using Rational ClearCase v. 7.0.1.1 with UCM, I have a problem here when using ClearCase's "Deliver from Stream to Alternate Target" functionality.
Imagine we have one project integration stream and two developer streams A and B derived from it. Now I change a file in stream A. I want the delevoper owning stream B to be able to use my work without me having to deliver the file to the integration stream yet, so I deliver from stream A to the alternate target stream B.
So far, so good. I go on making another change to the file but the stream B developer does not need this change, so I don't deliver it to him.
After some more time, I deliver my work to the main integration stream. This works fine, although I wonder why ClearCase marks the merge as a normal "Merged" instead of "Merged (trivial)" – no one except me has made changes to the file.
After the delivery, a new baseline is created on the main integration stream.
The real problem arises when developer B tries to rebase his stream. Since developer B has never made any changes to the file, I'd expect the merge to be a trivial one with no interaction necessary. But what happens is that developer B is forced to resolve a merge conflict on that file graphically, letting him choose between the base version on the integration stream, the version I delivered to him and the version that I delivered to the integration stream.
The confusion goes on when after resolving the merge and completing the rebase, developer B wants to perform a delivery to the main integration stream. Apart from the activity that I originally delivered to him, he is also offered to deliver an activity that is named rebase_…, which I would never expect to be offered for delivery.
Am I missing something here? Are we using ClearCase incorrectly or is this a known limitation / bug? Has anyone experience with this functionality?
Thanks in advance for your help!
Jan
Best Answer
Actually, when I look at the version tree, the source of the conflict during the rebase is clear:
When you re-read the way ClearCase 3-way merge works, you see it needs to go back in the version tree in order to find a common ancestor to:
That common ancestor is Int/1
Now it is possible that a common line has changed between those two version since:
If a common line has been modified (from A/1) both in A/2 and A/3... there is a reason for a manual merge resolution right there!
(I am testing this right now)
Got it! Conflict achieved!
Continuing on my previous experiment:
Let's make a new modif in Stream A:
Delivering that directly to B:
(Trivial merge)
Now let's COMPLETELTY CHANGE the content of that file:
And delivering to Int, with a new baseline put right after the deliver:
(another trivial merge)
What about a rebase from B?
There you have it: a nice conflict between two incompatible changes from the common ancestor.
Here is the picture to illustrate that:
.