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

Question

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

Answer 1

一个分支是一个经典版本的方式并行版本给定文件的历史记录：请参阅“When should you branch”

一个Stream is not a branch：它只是能记住任何视图引用什么基线流的元数据等着瞧。
当你创建一个Stream时，没有任何事情发生（没有分支被创建）。
但是一个流名称将在检出文件时使用：任何视图都将设置其配置规范以创建一个以Stream命名的分支，以便隔离development effort in said branch。
（请参阅“How do I create a snapshot view of some project or stream in ClearCase?‘）

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

所以，如果您有任何可写的成分，流可以被视为分支的模板：

• 你申报你在需要什么流（你想看什么基线）
• 你在那个流
• 创建视图的任何结帐时会产生的流而得名分支。

（这就是为什么这么多的UCM用户“分支”混合或等同于“流”）

但是，如果你在你的项目中唯一的非可写的组件，然后流只是名单您希望在所有视图中看到的基线（组件上的标签）。
这成为一种可视化机制，可用于测试您只需访问一组组件集的精确版本以测试您的系统的环境。
在这种情况下，将不会创建任何分支，因为不会对任何文件进行检出：组件在UCM项目中被声明为不可写。

---

流和分支之间的另一个主要区别是在一分层结构（母小河/子流）的组织流的。
这个层次结构根本不为分支存在：当你有3个分支A，B，C：

• 你不知道从哪里分支A合并一旦你完成它的工作。
• 任何合并你具有相同的含义：A->B，或C->A，或B->C，或...

随着流，你会：

MyProject_Int 
| 
--MyProject_Dev 
    | 
    -- MyProject_Feature1 

流的层次是有到：

• 介绍一个可能的合并工作流程（你知道你在哪里ld从一个Stream合并到另一个：即它的父代。它不是强制性的，但至少你必须知道的一个可视化的方式：
  • Feature1，一旦发育完全，会回来（被合并）MyProject_Dev（其父流），并认为：
  • MyProject_Dev一旦达到稳定状态，就可以合并到其母流MyProject_Int中，其中可以进行集成测试而开发在MyProject_Dev中不间断地继续。
• 添加意义的合并：
  • 从子流其父母或其他父流合并（例如，你可以直接从MyProject_Feature1如果你要合并到MyProject_Int ）被称为deliver。
  • 来自父流合并（如MyProject_Dev），以即时子流（如（MyProject_Feature1）被称为rebase。
    其目的是为了确保Feature1与的Dev最新的变化发展，为了做出最终实现尽可能无痛：定期底垫，代码的通用集合不会有分歧来自这两个流衍生出来的两个分支的两个并行历史之间太多

。请记住，这两个UCM操作deliver和rebase的核心只不过是两个分支A和B之间的简单合并。
但是，由于它们的名称，您知道您不会合并之间的任何两个分支之间，而是在子流与父流之间（deliver），或者在父流与子流之间（ rebase）。