问题描述
将Rational ClearCase v。7.0.1.1与UCM一起使用时，在使用ClearCase的从流交付到备用目标功能时，我在这里遇到问题。
想象一下我们拥有一个项目集成流以及从中派生的两个开发人员流A和B。现在，我在流A中更改文件。我希望拥有流B的Delevoper能够使用我的工作，而不必将文件传递到集成流，因此我从流A传递到备用目标流B。 / p>
到目前为止，很好。我继续对文件进行了另一处更改，但是流B开发人员不需要此更改，因此我不会将其交付给他。
再过一段时间后，我将工作交付给主要的集成流。效果很好，尽管我不知道为什么ClearCase将合并标记为普通的合并而不是合并（琐碎）-除了我之外，没有人对文件进行过更改。
交付后，将在主集成流上创建一个新的基准。
真正的问题出现在开发人员B尝试重新建立其流基础时。由于开发人员B从未对文件进行任何更改，因此我希望合并是一件微不足道的操作，不需要进行任何交互。但是发生的是，开发人员B被迫以图形方式解决该文件上的合并冲突，从而让他可以在集成流的基础版本，我提供给他的版本以及我交付给集成流的版本之间进行选择。
当解决合并并完成变基之后，开发人员B想要执行向主集成流的交付时，混乱就继续了。除了我最初提供给他的活动之外，还向他提供了一个名为rebase _...的活动，我从没期望过提供该活动。
我在这里想念什么吗？我们使用ClearCase的方式有误还是已知的限制/错误？有人有使用此功能的经验吗？
提前感谢您的帮助！
Jan
实际上，当我查看版本树时，变基期间的冲突根源很清楚：
重新阅读，您会看到它需要回到版本树中才能找到一个共同的祖先：
- 来源（Int / 2）
- 目的地（B / 1）
该共同祖先是Int / 1
现在，由于以下两种情况，这两个版本之间的共同点可能已更改：
- 上一个基准库（Int / 2）的来源来自A / 3
- th最后一个目标的目的地（B / 1）来自A / 2
- 公共祖先（Int / 1）来自A / 1
如果同时修改了A / 2和A / 3中的公共行（从A / 1），则有理由手动进行合并解析！
（我现在正在测试）
Got它！
继续我的：
让我们在流A中进行新的修改：
M：\vonc_test_dat_a\adev\test> ct co -nc aFile.txt
M：\vonc_test_dat_a\从A到B的adev\test> echo modif> aFile.txt
M：\vonc_test_dat_a\adev\test> ct ci -nc aFile.txt
M： \vonc_test_dat_a\adev\test>类型aFile.txt
在Int
上完成的第一行从Int
的第二行A由附加项传递给B first
A交付给Int，B不需要A对B的
修改
直接将其交付给B：
M：\vonc_test_dat_a\adev\test> ct交付-至vonc_test_dat_b-目标Test_DAT_B @ \myPVob -cact -gmerge -force
更改将交付给非默认tar在当前项目 Test_DeliverToAlternateTarget中获取流：
从：流 Test_DAT_A
到：流 Test_DAT_B
使用目标视图： vonc_test_dat_b。
此操作中包含的活动：
activity：test_dat_a @ \myPVob vonc test_dat_a
琐碎的合并： M：\vonc_test_dat_b\adev\test\aFile.txt与基数 M：\vonc_test_dat_b\adev\test\aFile.txt @@ \main\Test_DAT_Int\Test_DAT_A\2相同。
复制 M：\vonc_test_dat_b\adev\test\aFile.txt @@ \main\Test_DAT_Int\Test_DAT_A\3以输出文件。
传递已合并
M：\vonc_test_dat_a\adev\test> ct传递-target Test_DAT_B @ \myPVob -cact -complete -force
（临时合并）
现在，让我们完全更改该文件的内容：
M：\vonc_test_dat_a\adev\test> ct co -nc aFile.txt
M：＼ ＼vonc_test_dat_a\adev\test>回显更改第一行> aFile.txt
M：\vonc_test_dat_a\adev\test> ct ci -nc aFile.txt
M： \vonc_test_dat_a\adev\test>类型aFile.txt
更改第一行
并交付给Int，并在交付之后立即放置新的基准：
M：\vonc_test_dat_a\adev\test> ; ct传递-力
M：\vonc_test_dat_a\adev\test> ct传递-力-完整
M：\vonc_test_dat_a\adev\test> ct mkbl -comp ADV_TST @ ＼ PVmyPVob -view vonc_test_dat_int TST_DAT1.2.0
（另一个琐碎的合并）
什么
M：vonvon_test_dat_b\adev\test> ct rebase -bas TST_DAT1.2.0
前进至组件 ADV_TST的基准 TST_DAT1.2.0
更新基础视图的配置规范...
创建集成活动...
设置集成活动...
合并文件...
从版本 \main\Test_DAT_Int\Test_DAT_B\3中检出 M：\vonc_test_dat_b\adev\test\aFile.txt。
附加活动：
活动：rebase.Test_DAT_B.20090707.163300@\myPVob将Test_DAT_B重新设置为2009年7月7日下午4:33:00。
需要合并 M：\vonc_test_dat_b\adev\test\aFile.txt [到\main\Test_DAT_Int\4基础＼totomain\Test_DAT_Int\Test_DAT_B\CHECKEDOUT ＼main\T
est_DAT_Int\3]
************************************
<<<档案1：M：\vonc_test_dat_b\adev\test\aFile.txt @@ \main\Test_DAT_Int\3
>>档案2：M：\vonc_test_dat_b\adev\test\aFile.txt @@ \main\Test_DAT_Int\4
>>档案3：M：\vonc_test_dat_b\adev\test\aFile.txt
**************************** *****
--------- [已更改1-4文件1] ---------- | --------- [已更改为1文件2] ---------
在Int上完成的第一行|更改第一行
来自Int的第二行|-
A的加法将传递到B fir + |
由A进行的修改将传递给I + |
-|
***自动：对文件2应用更改[第1行]
============
=============
----------- [4个文件之后1] ------------ || ---------- [插入5个文件3] ----------
-|由A修改为B
|-
是否要在文件3中进行插入？ [是]否
============
===========
合并的输出在 M：\ vonc_test_dat_b\adev\test\aFile.txt。
记录的 M：\vonc_test_dat_b\adev\test\aFile.txt的合并。
必须进行构建和测试，以确保正确完成所有合并和配置更改。
确认构建和测试后，运行 cleartool rebase -complete。
有了它：共同祖先的两个不兼容的更改之间存在很好的冲突。
以下是说明图片的图片：
。
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:
- 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:
.
这篇关于ClearCase希望在交付到备用目标后合并未更改的文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！