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

Question

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

Answer 1

分支是一种经典的版本控制方式,用于并行化给定文件的版本历史记录:请参阅" 何时应该分支 "

一个流是不是一个分支:它只是能记住什么基线引用该流会看到任何视图中的元数据.
创建Stream时,不会发生任何事情(不创建分支).
但是在签出文件时将使用Stream 名称:任何视图都将设置其配置规范,以便创建以Stream命名的分支,以隔离所述分支中的开发工作.
(请参阅" 如何在ClearCase中创建某个项目或流的快照视图？ ")

这就是充分命名Stream的重要原因:如果我创建一个名为" VonC" 的Stream ,你最终会看到(在任何修改过的文件的版本树中)一个名为" VonC" 的分支:分支的目的是什么" VonC" ？
如果我创建一个名为" REL2.2_FIX" 的Stream ,您将看到名为" REL2.2_FIX"的分支,并将推断引用该Stream的任何视图都可以在2.2版本上生成修复:一个更有用的名称.(这就是为什么我不喜欢" 每个开发者模型的一个流 ")

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

• 您在流中声明了所需内容(您希望看到的基线)
• 您在该流上创建一个视图
• 任何结账都会创建一个以 Stream 命名的分支.

(这就是为什么这么多UCM用户将"Stream"与"branch"混合或等同的原因)

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

Stream和分支之间的另一个主要区别是层次结构中Stream的组织(父Stream /子Streams).
对于分支,该层次结构根本不存在:当您有3个分支A时B,C:

• A一旦完成工作,你就不知道在哪里合并.
• 你做任何合并具有相同的含义:A->B或C->A,或者B->C,还是......

使用Stream,您将拥有:

MyProject_Int
 |
 --MyProject_Dev
    |
    -- MyProject_Feature1

Streams的层次结构是:

• 介绍一个可能的合并工作流程(你知道你应该从一个Stream合并到另一个Stream:即它的父级.它不是强制性的,但至少你有一种直观的方式知道:
  • Feature1一旦完全开发,将返回(合并到)MyProject_Dev(其父流),并且:
  • MyProject_Dev一旦达到稳定状态,就可以合并到其父流中MyProject_Int,可以在开发不间断的情况下进行集成测试MyProject_Dev.
• 为这些合并添加含义:
  • 从子流其父母或其他父流合并(例如,你可以直接从合并MyProject_Feature1到MyProject_Int被称为如果您有)deliver.
  • 从父流(如MyProject_Dev)合并到直接子流(如(MyProject_Feature1)被称为a rebase.
    其目的是确保Feature1使用最新的变化开发,Dev以使最终的交付尽可能无痛:定期在这两个Streams派生的两个分支的两个并行化历史之间,共同的代码集不会有太大分歧.

请记住,这两个UCM操作deliver和rebase是,在他们的核心,不超过两个分支之间的简单合并的更多A和B.
但是,由于它们的名称,您知道不仅仅在任何两个分支之间合并,而是在子流和父Stream(deliver)之间,或者在父Stream和子Stream(rebase)之间合并.