Branching: branches versus streams

In the course of a collaborative development project, you may find it useful to split off the codeline into multiple codelines, each having a distinct intended purpose. For example, when a certain milestone is reached in development, you may choose to copy the code—also known as branching it—into a new codeline for testing, thereby creating a QA branch. After it passes all tests, it is copied up to the Beta test line where it is subjected to real-world use. Later, you may choose to merge one or more of these new branches back into the main codeline.

Streams: branches with additional intelligence

Streams:

• can be used to manage files in a way that resembles branches, but with additional functionality and structure
• guide merging and branching actions to support stability and innovation
• are ideal for implementing the mainline branching model, in which less stable streams first merge down changes to keep up to date with their parent stream, then copy up to the parent when the code or content is more stable
• eliminate much of the administrative work needed to define branches, create workspaces, and manage merges
• enable the generation of views for associated workspaces, so you don't need to update views manually to reflect changes to your stream structure

When you create a stream, you configure a stream specification. In the stream spec, you specify the type of stream, and provide information about the files it is associated with, its relationship to other streams, and how files are to be treated for branching and merging.

The stream type indicates the stability of the stream relative to other streams.

The stream’s path information determines:

• which files to populate the workspace with
• which files child streams are allowed to branch
• which changelist to lock the files at

Parent labeling specifies how the stream relates to other streams, helping to determine how change flows through the set of streams.