ClearCase中分支和流之间的区别？ [英] Difference between branches and streams in ClearCase?

问题描述

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

What is difference between branches and streams in ClearCase?

推荐答案

分支是一种经典的版本控制方法，可以并行化历史记录给定文件的版本：请参阅 何时应分支

A branch is a classic versioning way to parallelize the history of versions for a given file: See "When should you branch"

A Stream不是 分支 ：它只是一种元数据，能够记住任何引用Stream的视图将看到的基线。

当您创建Stream时，什么也没发生（没有创建分支）。

但是检出文件时将使用Stream的 name ：任何视图都会设置其配置规范为了创建一个以Stream命名的分支，以便隔离在该分支中的开发工作。

（请参阅 如何在ClearCase中创建某些项目或流的快照视图？）

A Stream is not a branch: it is just a metadata able to memorize what baseline any view referencing that Stream will see.
When you create a Stream, nothing happen (no branch is created).
But a Stream name will be used when a file is checked out: any view will set its config spec in order to create a branch named after the Stream in order to isolate the development effort in said branch.
(See "How do I create a snapshot view of some project or stream in ClearCase?")

这是为什么适当命名一个Stream如此重要：如果我创建一个名为 VonC 的Stream，您最终将（在任何已修改文件的版本树中）看到一个名为 VonC ：分支 VonC 的目的是什么？

如果我创建一个名为 REL2.2_FIX 的流，则将看到名为 REL2.2_FIX ，并将推断出存在引用Stream的任何视图以对版本2.2进行修复：一个更有用的名称。 （这就是为什么我不喜欢 每个开发人员模型一个流的原因）

This is why it is important to adequately name a Stream: If I create a Stream named "VonC", you will eventually see (in the version tree for any modified file) a branch named "VonC": what is the purpose of a branch "VonC"?
If I create a Stream named "REL2.2_FIX", you will see branches named "REL2.2_FIX" and will infer that any view referencing that Stream is there to produce fixes on the release 2.2: a much more useful name. (This is why I don't like the "one stream per developer model")

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

So if you have any writable component, a Stream could be considered as a template for branches:

• 您在流中声明所需的内容（想要查看的基线）


• 您在该流上创建视图


• 任何checkout将在Stream之后创建一个名为 的分支。

• You declare what you need in a stream (what baseline you want to see)
• You create a view on that stream
• Any checkout will create a branch named after the Stream.

（这就是为什么许多UCM用户混合使用的原因或将 Stream等同于 branch）

(And that is why so many UCM users mix or equate "Stream" with "branch")

但是，如果您的项目中只有不可写组件，那么Stream只是基线列表（标签在

这将成为一种可视化机制，对测试环境非常有用，在该环境中，您只需要访问一组组件的精确版本即可：测试您的系统。

我在这种情况下，将不会创建任何分支，因为将不会对任何文件进行检出：该组件在UCM项目中被声明为不可写。

But if you have only non-writable components in your project, then a Stream is just the list of baselines (labels on components) that you want to see in any view you will create on said Stream.
That becomes a visualization mechanism, useful for testing environment where you only need to access precise versions of a set of components in order to test your system.
In that case, no branches will ever be created, since no checkout will ever be made on any file: the component are declared non-writable in the UCM project.

Stream和分支之间的另一个主要区别是层次结构中的Stream组织（父Stream /子Streams）。

该分支根本不存在该层次结构：当您有3个分支 A ， B ， C ：

The other major difference between a Stream and a branch is the organization of Stream in a hierarchy (parent Stream / sub-Streams).
That hierarchy simply don't exist for branches: when you have 3 branches A, B, C:

• 您不知道从分支 A合并的位置完成工作。


• 您进行的任何合并都具有相同的含义： A-> B 或 C-> A ，或 B-> C 或...

• you don't know where to merge from branch A once you have finish your work on it.
• any merge you do has the same meaning: A->B, or C->A, or B->C, or ...

使用Stream，您将拥有：

With Stream, you would have:

MyProject_Int
 |
 --MyProject_Dev
    |
    -- MyProject_Feature1

流的层次结构用于：

• 引入可能的合并工作流（您知道应该从一个Stream合并到另一个Stream的位置：即其父。这不是强制性的。 ，但至少您有一种直观的了解方式：
  
  
  
  
  • Feature1 ，一旦完全开发，将返回（合并到） MyProject_Dev （其父流），并且：
  
  
  • MyProject_Dev 一旦达到稳定状态，就可以合并到其父流 MyProject_Int 中，可以在 while 进行集成测试开发在 MyProject_Dev 中继续进行。
  
  
  • introduce a possible workflow of merges (you know where you should merge from one Stream to another: namely its parent. It is not mandatory, but at least you have a visual way of knowing that:
    • Feature1, once fully developed, will get back (be merged to) MyProject_Dev (its parent Stream), and that:
    • MyProject_Dev, once a stable state is reached, can be merged into its parent Stream MyProject_Int, where integration tests can be conducted while development go on uninterrupted in MyProject_Dev.
    
    
    • 从子流合并到其父级或任何其他父级流（例如，您可以直接从 MyProject_Feature1 到 MyProject_Int （如果需要））称为 交付 。
    
    
    • 从父流（例如 MyProject_Dev ）合并到直接子流（例如（ MyProject_Feature1 ）称为 rebase 。
      
      其目的是确保 Feature1 是用 Dev 的最新更改开发的，目的是使最终交付尽可能轻松：通过常规的重新设置，通用代码集不会从这两个数据流派生的两个分支的两个并行历史之间的差异太大。
    
    
    • merging from a sub-stream to its parent or any other parent stream (for instance, you can merge directly from MyProject_Feature1 to MyProject_Int if you have to) is called a deliver.
    • merging from a parent Stream (like MyProject_Dev) to an immediate sub-Stream (like (MyProject_Feature1) is called a rebase.
      Its purpose is to ensure that Feature1 is developed with the latest changes of Dev, in order to make the final deliver as painless as possible: with regular rebases, the common set of code would not have diverged too much between the two parallelized histories of those two branches derived from those two Streams.

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

    Keep in mind that those two UCM operations deliver and rebase are, at their core, no more than simple merges between two branches A and B.
    However, because of their names, you know that you don't merge just between any two branches, but between a sub-Stream and a parent Stream (deliver), or between a parent Stream and a sub-Stream (rebase).

    这篇关于ClearCase中分支和流之间的区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！