ClearCase wants to merge unchanged files after deliver to alternate target

Question

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

Answer 1

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:

• the source (Int/2)
• the destination (B/1)

That common ancestor is Int/1

Now it is possible that a common line has changed between those two version since:

• the source of the last rebase (Int/2) comes from A/3
• the destination of the last rebase (B/1) comes from A/2
• the common ancestor (Int/1) comes from A/1

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:

M:vonc_test_dat_aadevest>ct co -nc aFile.txt
M:vonc_test_dat_aadevest>echo modif by A to B>>aFile.txt
M:vonc_test_dat_aadevest>ct ci -nc aFile.txt

M:vonc_test_dat_aadevest>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
modif by A to B

Delivering that directly to B:

M:vonc_test_dat_aadevest>ct deliver -to vonc_test_dat_b -target Test_DAT_B@myPVob -cact -gmerge -force
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"
Trivial merge: "M:vonc_test_dat_badevestaFile.txt" is same as base "M:vonc_test_dat_badevestaFile.txt@@mainTest_DAT_IntTest_DAT_A2".
Copying "M:vonc_test_dat_badevestaFile.txt@@mainTest_DAT_IntTest_DAT_A3" to output file.
Deliver has merged

M:vonc_test_dat_aadevest>ct deliver -target Test_DAT_B@myPVob -cact -complete -force

(Trivial merge)

Now let's COMPLETELTY CHANGE the content of that file:

M:vonc_test_dat_aadevest>ct co -nc aFile.txt
M:vonc_test_dat_aadevest>echo change first line>aFile.txt
M:vonc_test_dat_aadevest>ct ci -nc aFile.txt

M:vonc_test_dat_aadevest>type aFile.txt
change first line

And delivering to Int, with a new baseline put right after the deliver:

M:vonc_test_dat_aadevest>ct deliver -force
M:vonc_test_dat_aadevest>ct deliver -force -complete
M:vonc_test_dat_aadevest>ct mkbl -comp ADV_TST@myPVob -view vonc_test_dat_int TST_DAT1.2.0

(another trivial merge)

What about a rebase from B?

M:vonc_test_dat_badevest>ct rebase -bas TST_DAT1.2.0
Advancing to baseline "TST_DAT1.2.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_badevestaFile.txt" from version "mainTest_DAT_IntTest_DAT_B3".
  Attached activity:
    activity:rebase.Test_DAT_B.20090707.163300@myPVob  "rebase Test_DAT_B on 07/07/09 4:33:00 PM."
Needs Merge "M:vonc_test_dat_badevestaFile.txt" [to mainTest_DAT_IntTest_DAT_BCHECKEDOUT from mainTest_DAT_Int4 base mainT
est_DAT_Int3]
********************************
<<< file 1: M:vonc_test_dat_badevestaFile.txt@@mainTest_DAT_Int3
>>> file 2: M:vonc_test_dat_badevestaFile.txt@@mainTest_DAT_Int4
>>> file 3: M:vonc_test_dat_badevestaFile.txt
********************************
---------[changed 1-4 file 1]----------|---------[changed to 1 file 2]---------
first line done on Int                 | change first line
Second line from Int                   |-
Addition by A to be delivered to B fir+|
Modification by A to be delivered to I+|
                                      -|
*** Automatic: Applying CHANGE from file 2 [line 1]
============
============
-----------[after 4 file 1]------------|----------[inserted 5 file 3]----------
                                      -| modif by A to B
                                       |-
Do you want the INSERTION made in file 3?  [yes] no
============
============
Output of merge is in "M:vonc_test_dat_badevestaFile.txt".
Recorded merge of "M:vonc_test_dat_badevestaFile.txt".
Build and test are necessary to ensure that any merges and configuration changes were completed correctly.
When build and test are confirmed, run "cleartool rebase -complete".

There you have it: a nice conflict between two incompatible changes from the common ancestor.

Here is the picture to illustrate that:

.