What is difference between branches and streams in ClearCase?
相关问题
- How to restrict VOB read access in ClearCase (Wind
- preserving history when using mercurial ontop of c
- How to use ClearCase annotate sub-command?
- listing files checked in during last 2 days
- VS2008 and ClearCase : opening solution requests a
相关文章
- Provide version to independent files in clearcase
- How to undo checkout a file checked out from anoth
- Getting present working view in Clearcase
- What is the nature of a “MVFS filesystem” with Cle
- How to list only the name of the baselines in UCM
- Reuse a ClearCase view
- Value of using Git with ClearCase, AccuRev or Perf
- ClearCase: change branch type name?
A branch is a classic versioning way to parallelize the history of versions for a given file: See "When should you branch"
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?")
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")So if you have any writable component, a Stream could be considered as a template for branches:
(And that is why so many UCM users mix or equate "Stream" with "branch")
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.
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
once you have finish your work on it.A->B
, orC->A
, orB->C
, or ...With Stream, you would have:
The hierarchy of Streams is there to:
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 StreamMyProject_Int
, where integration tests can be conducted while development go on uninterrupted inMyProject_Dev
.MyProject_Feature1
toMyProject_Int
if you have to) is called adeliver
.MyProject_Dev
) to an immediate sub-Stream (like (MyProject_Feature1
) is called arebase
.Its purpose is to ensure that
Feature1
is developed with the latest changes ofDev
, 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.Keep in mind that those two UCM operations
deliver
andrebase
are, at their core, no more than simple merges between two branchesA
andB
.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
).