The mainline model is a well-established, standard branching model. In the mainline model there is one primary, long-lived codeline, called "mainline", where multiple, parallel paths of related development converge.

When you develop new product features, you create development branches off of the mainline where you can work independently without affecting the files in the mainline. When you complete your development efforts and have tested the new features, you integrate the changes from the development branch back into the mainline.

When a product is ready for release, you create a release branch off of the mainline. When you find bugs in a product release, you fix the bugs in the release stream and integrate the fixes back into the mainline.

Because, in the mainline model, you typically integrate changes made in development paths back into the mainline, you practically guarantee that bug fixes and new features propagate into future releases and development efforts.

Laura Wingerd, in her book "Practical Perforce", describes codeline stability in the mainline model using the “Tofu” scale. The Tofu scale defines the firmness of a codeline based on its relative position in a branching hierarchy that is drawn horizontally. The firmer the codeline, the more stable it is.

The Tofu scale helps you diagram your branching strategy and determine how to integrate changes between codelines. Branches drawn above the mainline, such as a release branch, are inherently more stable than branches drawn below the mainline, such as a development branch.

In streams, the position of a stream in the Stream Graph illustrates the stability of the stream in respect to other streams.

A stream's relative position on the Tofu scale also determines how you propagate changes between streams. For example, because softer branches can more easily absorb the risk and effort of merging, you typically merge changes from the more stable to less stable streams, such as from a release stream into the mainline stream or from the mainline stream into a development stream.

Because firmer branches are less capable of absorbing the risk and the effort of merging, the process of propagating changes from a less stable stream into a more stable stream has you first merge changes from the more stable stream into the less stable stream and then copy the resulting files from the less stable stream back to the more stable stream. You can summarize this integration process in terms of the Tofu scale as merge down, copy up.

This "merge down, copy up" practice assures that merging is done only when necessary, and always in the more forgiving of the two streams involved.

A well-defined codeline policy specifies workflow and procedures that help maintain the integrity of codelines. In classic Perforce, administrators enforce codeline policy using triggers and scripts that operate behind the scenes and have little or no visibility to users.

With streams, administrators define workflows and procedures using functionality built into the streams framework that can reduce the reliance on triggers and scripts to enforce workflow and codeline policy.

Additionally, when propagating changes across streams, the Stream Graph generates hints and visual cues that help users make good decisions about what to do and when to do it.

It's important to note that although streams helps users follow codeline policy and warns users when they try to go outside the established parameters for a code line, in most cases, it does not prevent users from continuing past the warning and overriding the default behavior if that is what they need to do.

The same is true from the Perforce Administrator's perspective. Although the out-of-the-box workflow and stream types might satisfy the needs of most customers, you can customize streams to formulate policies and establish workflow for most codeline models and branching strategies.

Course - Using Streams to Simplify Codeline Management