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:
.
Best Answer
What is described by skwllsp can be be done in a dynamic view through the use of extended pathnames
with
xx
being the version number you want to restore.But should you have made multiple checkins, including some you want to cancel, ClearCase allows you to cancel part of the previous checkins through Subtractive Merge
See IBM "to remove contributions of some versions" (and
merge
man page)Finally, the one thing to not do is a
rmver
.This command destroys information irretrievably and this is rarely a good thing.