ClearCase中分支和流之间的区别？

Question

ClearCase中分支和流之间有什么区别？

Answer 1

分支是一种经典的版本控制方式，用于并行化给定文件的版本历史记录：请参阅“When should you branch”

Stream is not a branch ：它只是一个能够记住引用该流的任何视图的基线的元数据。
当你创建一个Stream时，没有任何事情发生（没有创建分支） 但是在签出文件时将使用Stream name ：任何视图都将设置其配置规范，以便创建以Stream命名的分支，以隔离development effort in said branch。<登记/> （参见“How do I create a snapshot view of some project or stream in ClearCase?”）

这就是充分命名流的重要性：如果我创建一个名为“VonC”的流，您最终会看到（在任何修改过的文件的版本树中）一个名为“{{1”的分支}：“分支”VonC“的目的是什么？
如果我创建名为“VonC”的流，您将看到名为“REL2.2_FIX”的分支，并将推断引用该Stream的任何视图都可以在2.2版本上生成修复：更有用的名称。 （这就是为什么我不喜欢“one stream per developer model”）

因此，如果您有任何可写组件，可以将Stream视为分支的模板：

• 您在流中声明所需内容（您希望看到的基线）
• 您在该流上创建视图
• 任何结帐都会在Stream之后创建一个名为的分支。

（这就是为什么这么多UCM用户将“Stream”与“branch”混合或等同的原因）

但是如果你的项目中只有不可写的组件，那么Stream就是你想要在你在Stream上创建的任何视图中看到的基线列表（组件上的标签）。
这成为一种可视化机制，对于测试环境非常有用，您只需要访问一组组件的精确版本即可测试系统。
在这种情况下，不会创建任何分支，因为不会对任何文件进行检出：组件在UCM项目中被声明为不可写。

---

Stream和分支之间的另一个主要区别是层次结构中的组织流（父流/子流）。
对于分支，该层次结构根本不存在：当您有3个分支REL2.2_FIX，A，B时：

• 完成工作后，您不知道从分支C合并到哪里。
• 您执行的任何合并具有相同的含义：A，或A->B，或C->A，或...

使用Stream，您将拥有：

B->C

Streams的层次结构是：

• 介绍一个可能的合并工作流程（你知道你应该从一个Stream合并到另一个Stream：即它的父级。它不是强制性的，但至少你有一种可视方式知道：
  • MyProject_Int | --MyProject_Dev | -- MyProject_Feature1 ，一旦完全开发，将返回（合并到）Feature1（其父流），并且：
  • MyProject_Dev，一旦达到稳定状态，就可以合并到其父流MyProject_Dev，其中集成测试可以在进行，而开发在{{ 1}}。
• 为这些合并添加含义：
  • 从子流合并到其父流或任何其他父流（例如，如果必须，可以直接从MyProject_Int合并到MyProject_Dev）称为 {{ 1}} 即可。
  • 从父流（如MyProject_Feature1）到直接子流（如（MyProject_Int）的合并称为 deliver 。
    > 其目的是确保MyProject_Dev与MyProject_Feature1的最新变化一起开发，以便尽可能轻松地进行最终传递：通过常规变换，常见的代码集也不会发生分歧这两个分支的两个并行化历史之间的差异很大，来自这两个Streams。

请注意，这两个UCM操作rebase和Feature1的核心只不过是两个分支Dev和deliver之间的简单合并。 /> 但是，由于它们的名称，您知道不仅仅在任何两个分支之间合并，而是在子流和父流（rebase）之间或在父级之间合并流和子流（A）。