tags:

views:

1745

answers:

2

Hi everyone,

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

+2  A: 

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.

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.

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:

M:\>ct mkproj -in folder:ADV_Tests@\myPVob Test_DeliverToAlternateTarget@\myPVob
M:\>ct mkstream -int -in Test_DeliverToAlternateTarget@\myPVob Test_DAT_Int@\myPVob
Created stream "Test_DAT_Int".
M:\>ct mkview -tag vonc_test_dat_int -stream Test_DAT_Int@\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct rebase -bas ADV_TST0.0.0
Adding baseline "ADV_TST0.0.0" of new component "ADV_TST"
M:\vonc_test_dat_int\adev\test>ct rebase -complete

Let's make the component writable:

M:\vonc_test_dat_int\adev\test>ct chproj -amodcomp component:ADV_TST@\myPVob Test_DeliverToAlternateTarget@\myPVob
M:\vonc_test_dat_int\adev\test>ct chstream -generate Test_DAT_Int@\myPVob
M:\vonc_test_dat_int\adev\test>ct setcs -stream

A will create a file on Int, add it, modify it, and then put a baseline:

M:\vonc_test_dat_int\adev\test>ct mkact test_dat_int
M:\vonc_test_dat_int\adev\test>echo first line done on Int>aFile.txt
M:\vonc_test_dat_int\adev\test>ct co -nc .
M:\vonc_test_dat_int\adev\test>ct mkelem -nc aFile.txt
M:\vonc_test_dat_int\adev\test>ct ci -nc .
M:\vonc_test_dat_int\adev\test>ct ci -nc aFile.txt

M:\vonc_test_dat_int\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_int\adev\test>echo Second line from Int>>aFile.txt
M:\vonc_test_dat_int\adev\test>ct ci -nc aFile.txt

M:\vonc_test_dat_int\adev\test>type aFile.txt
first line done on Intct mkview vonc_
Second line from Int

M:\vonc_test_dat_int\adev\test>ct mkbl -comp ADV_TST@\myPVob TST_DAT1.0.0
Created baseline "TST_DAT1.0.0" in component "ADV_TST".

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:

M:\vonc_test_dat_int\adev\test>ct mkstream -in Test_DAT_Int@\myPVob Test_DAT_A@\myPVob
M:\vonc_test_dat_int\adev\test>ct mkstream -in Test_DAT_Int@\myPVob Test_DAT_B@\myPVob
M:\vonc_test_dat_int\adev\test>ct mkview -tag vonc_test_dat_a -stream Test_DAT_A@\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct mkview -tag vonc_test_dat_b -stream Test_DAT_B@\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_a -bas TST_DAT1.0.0
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_a -complete
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_b -bas TST_DAT1.0.0
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_b -complete

A will make a modification on his stream A, to be delivered to B:

M:\vonc_test_dat_a\adev\test>ct mkact test_dat_a
M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
Created branch "Test_DAT_A" from "aFile.txt" version "\main\Test_DAT_Int\2".
M:\vonc_test_dat_a\adev\test>echo Addition by A to be delivered to B first>>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt

Delivering directly from stream A to B:

M:\vonc_test_dat_a\adev\test>ct deliver -to vonc_test_dat_b -target Test_DAT_B@\myPVob -cact -gmerge
Changes to be DELIVERED to non-default target stream in current project "Test_DeliverToAlternateTarget":
          FROM: stream "Test_DAT_A"
          TO: stream "Test_DAT_B"
Using target view: "vonc_test_dat_b".
Activities included in this operation:
        activity:test_dat_a@\myPVob   vonc        "test_dat_a"
Created branch "Test_DAT_B" from "M:\vonc_test_dat_b\adev\test\aFile.txt" version "\main\Test_DAT_Int\2".
Checked out "M:\vonc_test_dat_b\adev\test\aFile.txt" from version "\main\Test_DAT_Int\Test_DAT_B\0".
  Attached activity:
    activity:deliver.Test_DAT_A.20090707.123738@\myPVob  "deliver Test_DAT_A on 07/07/09 12:37:38 PM."
Needs Merge "M:\vonc_test_dat_b\adev\test\aFile.txt" [to \main\Test_DAT_Int\Test_DAT_B\CHECKEDOUT from \main\Test_DAT_Int\Test_DAT_A\1 b
ase \main\Test_DAT_Int\2]
Trivial merge: "M:\vonc_test_dat_b\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\
2".
Copying "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\Test_DAT_A\1" to output file.
Deliver has merged
M:\vonc_test_dat_a\adev\test>ct deliver -target Test_DAT_B@\myPVob -force -complete

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:

M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_a\adev\test>echo Modification by A to be delivered to Int, B does not need it>>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt

M:\vonc_test_dat_a\adev\test>ct deliver
Changes to be DELIVERED to default target stream in project "Test_DeliverToAlternateTarget":
          FROM: stream "Test_DAT_A"
          TO: stream "Test_DAT_Int"
Using target view: "vonc_test_dat_int".
Activities included in this operation:
        activity:test_dat_a@\myPVob   vonc        "test_dat_a"
Do you wish to continue with this deliver operation?  [no] yes
Checked out "M:\vonc_test_dat_int\adev\test\aFile.txt" from version "\main\Test_DAT_Int\2".
  Attached activity:
    activity:deliver.Test_DAT_A.20090707.124108@\myPVob  "deliver Test_DAT_A on 07/07/09 12:41:08 PM."
Needs Merge "M:\vonc_test_dat_int\adev\test\aFile.txt" [to \main\Test_DAT_Int\CHECKEDOUT from \main\Test_DAT_Int\Test_DAT_A\2 base \main
\Test_DAT_Int\2]
Trivial merge: "M:\vonc_test_dat_int\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_int\adev\test\aFile.txt@@\main\Test_DAT_
Int\2".
Copying "M:\vonc_test_dat_int\adev\test\aFile.txt@@\main\Test_DAT_Int\Test_DAT_A\2" to output file.
Deliver has merged
M:\vonc_test_dat_a\adev\test>ct deliver -force -complete

(Another trivial merge)

Let's put a baseline on Int:

M:\vonc_test_dat_a\adev\test>ct mkbl -nc -view vonc_test_dat_int TST_DAT1.1.0
Created baseline "TST_DAT1.1.0" in component "ADV_TST".
Begin incrementally labeling baseline "TST_DAT1.1.0".
Done incrementally labeling baseline "TST_DAT1.1.0".

Now, we switch to B, who begins with a little work of his own on another file:

M:\vonc_test_dat_b\adev\test>ct mkact test_dat_b
M:\vonc_test_dat_b\adev\test>echo myFile by B>aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct co -nc .
M:\vonc_test_dat_b\adev\test>ct mkelem -nc aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct ci -nc aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct ci -nc .

And then, suddenly, he has to rebase his work with what has been consolidated in Int:

M:\vonc_test_dat_b\adev\test>ct rebase -bas TST_DAT1.1.0
Advancing to baseline "TST_DAT1.1.0" of component "ADV_TST"
Updating rebase view's config spec...
Creating integration activity...
Setting integration activity...
Merging files...
Checked out "M:\vonc_test_dat_b\adev\test\aFile.txt" from version "\main\Test_DAT_Int\Test_DAT_B\1".
  Attached activity:
    activity:rebase.Test_DAT_B.20090707.125044@\myPVob  "rebase Test_DAT_B on 07/07/09 12:50:44 PM."
Needs Merge "M:\vonc_test_dat_b\adev\test\aFile.txt" [to \main\Test_DAT_Int\Test_DAT_B\CHECKEDOUT from \main\Test_DAT_Int\3 base \main\T
est_DAT_Int\Test_DAT_A\1]
Trivial merge: "M:\vonc_test_dat_b\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\
Test_DAT_A\1".
Copying "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\3" to output file.
Output of merge is in "M:\vonc_test_dat_b\adev\test\aFile.txt".
Recorded merge of "M:\vonc_test_dat_b\adev\test\aFile.txt".

M:\vonc_test_dat_b\adev\test>type aFile.txt
first line done on Int
Second line from Int
Addition by A to be delivered to B first
Modification by A to be delivered to Int, B does not need it

M:\vonc_test_dat_b\adev\test>ct rebase -complete

No conflicts at all: Trivial merges again.

B goes on working on his file:

M:\vonc_test_dat_b\adev\test>ct setact test_dat_b
M:\vonc_test_dat_b\adev\test>ct co -nc aFileByB.txt
M:\vonc_test_dat_b\adev\test>echo a modif by B to be delivered to Int>>aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct ci -nc aFileByB.txt

And then he delivers the all work to Int:

M:\vonc_test_dat_b\adev\test>ct deliver -cact
cleartool: Error: Activity "deliver.Test_DAT_A.20090707.123738" must be added to activity list to preserve baseline order in stream.
cleartool: Error: Activity "rebase.Test_DAT_B.20090707.125044" must be added to activity list to preserve baseline order in stream.
cleartool: Error: The list of activities specified is incomplete.
cleartool: Error: Unable to deliver selected activities.
cleartool: Error: Unable to deliver stream "Test_DAT_B".

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:

M:\vonc_test_dat_b\adev\test>ct deliver
Changes to be DELIVERED to default target stream in project "Test_DeliverToAlternateTarget":
          FROM: stream "Test_DAT_B"
          TO: stream "Test_DAT_Int"
Using target view: "vonc_test_dat_int".
Activities included in this operation:
        activity:deliver.Test_DAT_A.20090707.123738@\myPVob   vonc        "deliver Test_DAT_A on 07/07/09 12:37:38 PM."
        activity:test_dat_b@\myPVob   vonc        "test_dat_b"
        activity:rebase.Test_DAT_B.20090707.125044@\myPVob    vonc        "rebase Test_DAT_B on 07/07/09 12:50:44 PM."
Do you wish to continue with this deliver operation?  [no]

  Attached activity:
    activity:deliver.Test_DAT_B.20090707.131614@\myPVob  "deliver Test_DAT_B on 07/07/09 1:16:14 PM."
Needs Merge "M:\vonc_test_dat_int\adev\test" [to \main\Test_DAT_Int\CHECKEDOUT from \main\Test_DAT_Int\Test_DAT_B\1 base \main\Test_DAT_
Int\1]
********************************
<<< directory 1: M:\vonc_test_dat_int\adev\test@@\main\Test_DAT_Int\1
>>> directory 2: M:\vonc_test_dat_int\adev\test@@\main\Test_DAT_Int\Test_DAT_B\1
>>> directory 3: M:\vonc_test_dat_int\adev\test
********************************
-----------[ directory 1 ]-------------|---------[ added directory 2 ]---------
                                      -| aFileByB.txt  --07-07T12:50 vonc
*** Automatic: Applying ADDITION from directory 2
Recorded merge of "M:\vonc_test_dat_int\adev\test".
Created branch "Test_DAT_Int" from "M:\vonc_test_dat_int\adev\test\aFileByB.txt" version "\main\0".
Checked out "M:\vonc_test_dat_int\adev\test\aFileByB.txt" from version "\main\Test_DAT_Int\0".
  Attached activity:
    activity:deliver.Test_DAT_B.20090707.131614@\myPVob  "deliver Test_DAT_B on 07/07/09 1:16:14 PM."
Needs Merge "M:\vonc_test_dat_int\adev\test\aFileByB.txt" [to \main\Test_DAT_Int\CHECKEDOUT from \main\Test_DAT_B\2 base \main\0]
Trivial merge: "M:\vonc_test_dat_int\adev\test\aFileByB.txt" is same as base "M:\vonc_test_dat_int\adev\test\aFileByB.txt@@\main\0".

Copying "M:\vonc_test_dat_int\adev\test\aFileByB.txt@@\main\Test_DAT_B\2" to output file.
Deliver has merged
M:\vonc_test_dat_b\adev\test>ct deliver -complete

.

VonC
Interesting, though then I don't understand why this only happens in the special scenario with the delivery to an alternate target.By the way, stream A and B do use the same foundation baseline.
Jan
Fist of all, a huge "thank you" for all the effort and advice. To summarize, I understand that I have done everything correctly, although it may not be good practice use two streams if it is foreseeable that A and B will be working together.Remarkably, you cannot reproduce the problems that I can reproduce here. Could this really be a bug in CC? What patch version of the client are you using? Or would this be a server issue?
Jan
+4  A: 
VonC
Again, thank you so much for the detailed explanation and all your effort. It's a pity that CC isn't more intelligent, because technically it would be possible to resolve that conflict automatically. I guess for me this simply means to avoid deliveries to nondefault targets. I think the danger that the developer on stream B messes up A's work during rebase is too high.
Jan
Well... that's the price to pay with a sideway merge. The next 3-way merge on another branch will detect changes in the source *and* the destination, hence conflict. Actually, I wonder if any other 3-way-merge-enabled SCM would do that differently? I will have to test that with Git.
VonC
Good question. It's just that all the information is there fore ClearCase to determine which version would obviously be the correct one after the rebase.
Jan
I just realized that there is one workaround for this problem. If developer B is confronted with having to merge during his rebase operation, he can undo the rebase. Then developer A can do another delivery to stream B, containing the same versions he delivered to the integration stream. This is again a trivial merge. After that, developer B can rebase without any problems.
Jan
@Jan: that is indeed one workaround, but if it needs to be repeated over and over, it may also indicate the current workflow is not the "optimal" one. If you could share one stream instead of two, you would not have to deals with those extra merges.
VonC