The mainline model is a well-established, standard branching model. In the mainline model:
There is one main codeline, the mainline, where multiple paths of related development converge
Changes made in multiple, parallel paths of development are merged back into the mainline
All changes eventually flow to the mainline, guaranteeing that bug fixes and new features propagate into future releases and development efforts
In the mainline model, you have one main, long-lived codeline, which we will call “main.” To develop new features, you create development branches that contain the required files. When development is complete and the new features have been adequately tested, you integrate the changes back into the mainline.
When a product is ready for release, you create a release branch. You fix bugs in the release codeline and integrate the fixes back into the mainline.
In general, branches off of the mainline, such as a development or release branch, are short-lived. If permanent divergence of some branch is desirable, the mainline model records the ancestry of any particular divergent branch.
Laura Wingerd, in her book "Practical Perforce", uses the Tofu scale to describe the relative codeline stability in the mainline model. 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 more stable than branches drawn below the mainline, such as a development branch.
A codeline's relative position on the Tofu scale also helps you determine how to propagate changes between codelines. 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 branches, such as from a release branch into the main codeline or from the main codeline into a development branch.
Because firmer branches are less capable of absorbing the risk and the effort of merging, the process of propagating changes from a less stable branch into a more stable branch involves first merging changes from the more stable branch into the less stable branch and then copying the resulting files from the less stable branch back to the more stable branch. You can summarize this integration process in terms of the Tofu scale as merge down, copy up.
When multiple people simultaneously check out and modify the same files, Perforce identifies the differences in each file by comparing each file to the most recent common version of the file, called the base.
For example, suppose two users check out the same file and modify it simultaneously. If User 1 edits the file and submits their changes to the codeline before User 2 can submit their edits, User 2 must compare their newly modified file, called Yours, to both the base and the current version of the file submitted by User 1, which we call Theirs, determine how to resolve the differences, and then submit the resultant file to the codeline.
This same process and terminology applies when integrating changes between codelines.
Codeline policy defines rules governing how people use the objects contained in a codeline and how a codeline evolves over time.
For example, a policy might dictate:
How often changes must be submitted to a codeline
The types of changes that can be made to a codeline, such as enhancements, new features, bug fixes, and approved bug fixes
Who is permitted to submit changes to a codeline
The tests or review processes that modified objects must pass before they can be submitted to a codeline
Every codeline should have an associated policy.
Every codeline should have a curator. The codeline curator performs routine housekeeping tasks, enforces policy, and resolves ambiguities in policy when they arise.
The codeline curator also helps define the overall codeline design. There are many factors to consider when planning and designing a codeline for your site.
In most codeline lifecycle models, you create new codelines to support parallel development efforts. The codeline curator is typically responsible for identifying when and how to branch a codeline. When the policy relating to a subset of files in a branch diverges from the overall policy of the branch, it usually signifies the need for a new branch. For example, a release branch typically has a more restrictive integration policy than the main branch, while the integration policy in a development branch is typically less restrictive than the policy for the main branch.