在我的项目中,我们会从一些主流分支分支到重要的里程碑,例如 Beta 版和候选发布版。
一旦我们将构建交付给客户,我们就会将代码合并回主流。这是一个没有变基的简单交付操作。
现在,还有一些场景需要我们将一些非常旧的流(几乎已经过时)合并到主流中。我发现了两个可用的选项:
1)交付到替代目标
2)合并经理
我们的项目中不允许使用选项 1)。
我的问题是:
两者之间有什么区别,为什么要优先于另一个?
在我的项目中,我们会从一些主流分支分支到重要的里程碑,例如 Beta 版和候选发布版。
一旦我们将构建交付给客户,我们就会将代码合并回主流。这是一个没有变基的简单交付操作。
现在,还有一些场景需要我们将一些非常旧的流(几乎已经过时)合并到主流中。我发现了两个可用的选项:
1)交付到替代目标
2)合并经理
我们的项目中不允许使用选项 1)。
我的问题是:
两者之间有什么区别,为什么要优先于另一个?
简单的:
deliver to alternate target
(或deliver to default
就此而言)是一个 UCM 合并,它必须遵循 UCM 规则,特别是关于活动依赖关系,但也关于 Stream(你不应该deliver
从父 Stream 到子 Stream,应该是 a rebase
)
Merge Manager
是一个简单的 ClearCase 合并,在两个分支(而不是 Streams)之间,它可以将任何文件子集从一个分支A
传递到另一个分支B
,而无需遵循任何合并工作流。
我通常会看到为 UCM 由于神秘的“活动依赖”原因而阻止交付的情况选择了“合并管理器”,即使在没有的情况下也是如此。有关这种情况的示例,
请参阅“ Clearcase UCM - 交叉交付与向上交付? ”。
说“ deliver to alternate target
”是不允许的,意味着只有deliver to default
是,这意味着您必须遵循 Streams 层次结构建立的合并工作流程。UCM 合并为基线
之间的合并带来了更好的可视化,这意味着您知道给定组件的所有文件都已合并。
但是,合并管理器是一个普通的合并,它可以涉及任何两个分支和任何两个(或更多)文件。该合并没有更高的可见性:它是逐个文件的操作(而不是一个组件 - 或一组连贯的文件 - 一个)。