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_a\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_a\adev\test>echo modif by A to B>>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt
M:\vonc_test_dat_a\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
modif by A to B
Delivering that directly to B:
M:\vonc_test_dat_a\adev\test>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_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\2".
Copying "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\Test_DAT_A\3" to output file.
Deliver has merged
M:\vonc_test_dat_a\adev\test>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_a\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_a\adev\test>echo change first line>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt
M:\vonc_test_dat_a\adev\test>type aFile.txt
change first line
And delivering to Int, with a new baseline put right after the deliver:
M:\vonc_test_dat_a\adev\test>ct deliver -force
M:\vonc_test_dat_a\adev\test>ct deliver -force -complete
M:\vonc_test_dat_a\adev\test>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_b\adev\test>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_b\adev\test\aFile.txt" from version "\main\Test_DAT_Int\Test_DAT_B\3".
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_b\adev\test\aFile.txt" [to \main\Test_DAT_Int\Test_DAT_B\CHECKEDOUT from \main\Test_DAT_Int\4 base \main\T
est_DAT_Int\3]
********************************
<<< file 1: M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\3
>>> file 2: M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\4
>>> file 3: M:\vonc_test_dat_b\adev\test\aFile.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_b\adev\test\aFile.txt".
Recorded merge of "M:\vonc_test_dat_b\adev\test\aFile.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:
.
B and C are based on different baselines of A. Is it ok to do merges between B and C in both directions from B to C and vice versa
What you are describing is called sideway merges and you can see (following the link) that they comes with a price: merges will likely be non-trivial at some point.
In your case, though, if B did not touch the files that were merged (with non-trivial resolution) from A to C, then merges from A to B should be trivial (simple copy of the version stored in A on top of the one in B)
By merging from V to B, you would include potential modifications from C which you would have to eliminate during that merge.
In a more general way, you can rebase/deliver in whatever order you want, but some workflow can be rigged to produced non-trivial merges if they follow a "sideway" pattern as the previous link illustrate.
Best Answer
Those versions should be listed in the merge activity you has to create when you merged directly from A to C (using
findmerge
, I presume).The only problem is, did you create a special "merge" activity during that
findmerge
?You may just have reused the current activity on C, meaning that activity would contain versions from the current work on C, plus the versions merged from A.
The other approach would be to merge the same activities (the ones concerned by the findmerge from A to C) from A to B.
The next "normal" merge from B to C would:
Unless you have only one or two files to merge,
findmerge
is the command to use, because:In short,
findmerge
is your classical merge, able to read versions within UCM activities, but does a non-UCM merge (no hyperlink between UCM baselines).