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 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
, or C->A
, or B->C
, or ...With Stream, you would have:
MyProject_Int
|
--MyProject_Dev
|
-- MyProject_Feature1
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 Stream MyProject_Int
, where integration tests can be conducted while development go on uninterrupted in MyProject_Dev
.MyProject_Feature1
to MyProject_Int
if you have to) is called a deliver
.MyProject_Dev
) to an immediate sub-Stream (like (MyProject_Feature1
) is called a rebase
.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.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
).