{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 做个烂人 的问题《ClearCase wants to merge unchanged files after del》','https://www.manongdao.com/q-81379.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
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
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:
.
I am surprised by this conflict: since ClearCase does register the merge from Stream A to B, unless Stream B does not have the same foundation baseline (starting point for the branch, or initial label) than Stream A.
When you rebase from Int to B, you create an automatic "timeline" which links all the activities together.
Meaning, during the next deliver, B will have to deliver rebase even though no merge will be performed for all versions present in this changeset.
A few comments first:
you may want to avoid creating streams attached to resources (developer "A", developer "B"): if they are working on separate set of files for the same global "development effort", there should be only one Stream_FeatureF representing the task at hand.
A and B should then see the same LATEST of the same branch attached to that stream (no need to deliver from one stream to another)
If B constantly breaks A's work, then and only then a sub-stream can be created for the disruptive sub-feature which cannot be developed at the same time than the main Feature "F".
The deliver/rebase GUI does not display "Yes (trivial)" when a merge is trivial (see my test below). That does not mean the merge is not trivial (meaning that the base is the same than the source or the destination, see core concepts)
my test below respects the workflow of merges you describe, but shows only trivial merges.
What could explain non-trivial ones would be "evil twins" (a file added in one stream, but re-created from scratch in the other, with the same name)
All right, let's test this, assuming a Vob "adev" (stands for "development architecture", where my team stores its tools), with an UCM component ADV_TST in \adev\test.
ClearCase7.0.1 on Windows (although the Vob is actually on Unix)
Let's begin with a Test project, one Integration stream and one empty test component:
Let's make the component writable:
A will create a file on Int, add it, modify it, and then put a baseline:
Now, let's create two sub-stream, one for each developers (may be considered "bad practice" though), both initialized with the same baseline
TST_DAT1.0.0:A will make a modification on his stream A, to be delivered to B:
Delivering directly from stream A to B:
I confirm the GUI did not display Trivial although the textual output of the same deliver does mention
Trivial merge...A goes on working on '
aFile.txt' and delivers it to Int:(Another trivial merge)
Let's put a baseline on Int:
Now, we switch to B, who begins with a little work of his own on another file:
And then, suddenly, he has to rebase his work with what has been consolidated in Int:
No conflicts at all: Trivial merges again.
B goes on working on his file:
And then he delivers the all work to Int:
I do confirm he has to select all activities (not just his): the timeline set during the last rebase has linked all activities together.
Even though no merge will be done with Activity "deliver.Test_DAT_A.20090707.123738" and Activity "rebase.Test_DAT_B.20090707.125044", they have to be included:
.