将 Rational ClearCase v. 7.0.1.1 与 UCM 一起使用时，在使用 ClearCase 的“从流交付到备用目标”功能时，我遇到了问题。
想象一下，我们有一个项目集成流和从中派生出的两个开发人员流 A 和 B。 现在我更改流 A 中的文件。我希望拥有流 B 的开发人员能够使用我的工作，而无需将文件传送到集成流，因此我从流 A 传送到备用目标流
B。远了，真好。 我继续对文件进行另一次更改，但流 B 开发人员不需要此更改，因此我不将其交付给他。
一段时间后，我将我的工作交付给主集成流。 这工作得很好，尽管我想知道为什么 ClearCase 将合并标记为正常的“合并”而不是“合并（琐碎）”——除了我之外没有人对文件进行过更改。
交付后，将在主集成流上创建新的基线。
当开发人员 B 尝试对其流进行变基时，真正的问题就出现了。 由于开发人员 B 从未对文件进行过任何更改，因此我希望合并是一件微不足道的事情，不需要交互。 但发生的情况是，开发人员 B 被迫以图形方式解决该文件的合并冲突，让他在集成流上的基本版本、我交付给他的版本和我交付给集成流的版本之间进行选择。
当解决合并并完成变基后，开发人员 B 想要执行到主集成流的交付时，混乱就会继续存在。 除了我最初交付给他的活动之外，还向他提供了一个名为 rebase_... 的活动，这是我从未想到会提供的活动。
我在这里错过了什么吗？ 我们是否错误地使用了 ClearCase 或者这是一个已知的限制/错误？ 有人体验过此功能吗？
在此先感谢您的帮助！
扬
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）
实际上，当我查看版本树时，rebase期间冲突的根源很清楚：
时您重新阅读方式 ClearCase 3 -way 合并有效，您会看到它需要返回到版本树中才能找到一个共同祖先：
共同祖先是 Int/1
现在，这两个版本之间的共同点可能已发生变化，因为：
如果 A/2 和 A/3 中的公共行已被修改（来自 A/1）...则有一个手动合并解析的原因！
（我现在正在测试这个）
明白了！ 冲突达成！
继续我的之前的实验< /a>：
让我们在流 A 中进行一个新的修改：
将其直接传送到 B：（
简单合并）
现在让我们完全更改该文件的内容：
并传送到 Int，在传送之后放置一个新基线：（
另一个简单的合并）
来自 B 的变基怎么样？
现在你已经看到了：来自共同祖先的两个不兼容的更改之间发生了很好的冲突。
这是说明这一点的图片：
。
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:
That common ancestor is Int/1
Now it is possible that a common line has changed between those two version since:
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:
Delivering that directly to B:
(Trivial merge)
Now let's COMPLETELTY CHANGE the content of that file:
And delivering to Int, with a new baseline put right after the deliver:
(another trivial merge)
What about a rebase from B?
There you have it: a nice conflict between two incompatible changes from the common ancestor.
Here is the picture to illustrate that:
.
我对这种冲突感到惊讶：因为 ClearCase 确实注册了从流 A 到 B 的合并，除非流 B 没有与流 A 相同的基础基线（分支的起点或初始标签）。
当您从 Int 变基到 B 时，您创建了一个自动“时间线”，将所有活动链接在一起。
这意味着，在下一次交付期间，B 将必须交付变基，即使不会对此变更集中存在的所有版本执行合并。
首先有几点评论：
您可能希望避免创建附加到资源（开发人员“A”、开发人员“B”）的流：如果他们正在为同一全局“开发工作”处理单独的文件集，则应该有仅一个 Stream_FeatureF 代表手头的任务。
然后，A 和 B 应该看到附加到该流的同一分支的相同最新内容（无需从一个流传递到另一个流）
如果 B 不断破坏 A 的工作，那么只有这样才能为破坏性子功能创建一个子流，该子功能不能与主要功能“F”同时开发。
当合并微不足道（请参阅下面的测试）。 这并不意味着合并不是微不足道的（意味着基数与源或目标相同，请参阅核心概念）
我下面的测试尊重您描述的合并工作流程，但仅显示简单的合并.
可以解释不平凡的是“邪恶双胞胎”（在一个流中添加的文件，但在另一个流中从头开始重新创建，具有相同的名称）
好吧，让我们测试一下，假设有一个 Vob“adev”（代表“开发架构”，我的团队在其中存储其工具），在 \adev\test 中有一个 UCM 组件 ADV_TST。
Windows 上的 ClearCase7.0.1（尽管 Vob 实际上是在 Unix 上）
让我们从一个测试项目、一个集成流和一个空测试组件开始：
让我们使该组件可写：
A 将在 Int 上创建一个文件，添加它，修改它，然后设置基线：
现在，让我们创建两个子流，每个开发人员一个（尽管可能被认为是“不好的做法”），两者都使用相同的基线
TST_DAT1.0.0进行初始化：A 将使对他的流 A 进行修改，传送到 B：
直接从流 A 传送到 B：
我确认 GUI 没有显示 Trivial，尽管同一传送的文本输出确实提到 < code>简单合并...
A 继续处理 '
aFile.txt' 并将其传递给 Int：（另一个简单合并）
让我们在 Int 上放置一个基线：
现在，我们切换到 B，他从自己在另一个文件上的一些工作开始：
然后，突然间，他必须使用 Int 中合并的内容重新调整他的工作：
完全没有冲突：再次进行简单合并。
B 继续处理他的文件：
然后他将所有工作交付给 Int：
我确实确认他必须选择所有活动（不仅仅是他的）：上次 rebase 期间设置的时间线已链接了所有活动一起活动。
即使不会对 Activity "deliver.Test_DAT_A.20090707.123738" 和 Activity "rebase.Test_DAT_B.20090707.125044" 进行合并，它们也必须包含在内：
。
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.
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:
Let's make the component writable:
A will create a file on Int, add it, modify it, and then put a baseline:
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:A will make a modification on his stream A, to be delivered to B:
Delivering directly from stream A to B:
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:(Another trivial merge)
Let's put a baseline on Int:
Now, we switch to B, who begins with a little work of his own on another file:
And then, suddenly, he has to rebase his work with what has been consolidated in Int:
No conflicts at all: Trivial merges again.
B goes on working on his file:
And then he delivers the all work to Int:
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:
.