CM: THE NEXT GENERATION of Branching Standards

into play.  You specify the promotion level you wish as part of your context (along with Product and Stream), and your view now reflects all revisions that are (i.e. whose Updates are) at a status of that promotion level or higher, instead of always getting the latest.  Because your tools are aware of this promotion level capability, they can be adjusted to automatically provide such views, based on the Update status, without the need for writing configuration specs.  This is not easy to do with branch promotion management because branches are used for a wide variety of purposes, many of which are blurred.  

In a "main trunk" view, the promotion levels apply to revisions across the main trunk, and there are some complexities here.  But in a trunk per release (i.e. Stream) organization, promotion levels apply to the release trunk (i.e. Stream branch) for each file.

One of the key advantages of this approach, if your tools support the promotion level views, is that its each to roll back an Update - just roll back its state.  The view, that is, the promotion level configuration line, should automatically adjust itself, as long as this is an automated capability in your tool.  Now it's not quite that easy.  When you roll back an Update, you must also inspect dependents that are affected.  They too will have to be rolled back - but hopefully your tool automatically makes you aware of such dependency violations whenever you roll back (or promote!) the status of an Update.

One other thing to keep in mind is that while it may always (or usually) be fine to select all checked in code for a build, as you approach the end of release development, you do want to carefully control what code can be checked in, or more precisely, what work is authorized for creating an Update in the release Stream. Presumably, if you can't create an Update in a given Stream, you can't check out files to make the changes.

4.  Files can be checked in to the repository without breaking the build
One of the by-products of branchless promotion levels, is that you can easily insert new promotion levels.  There's no need for a new set of promotion branches, just an understanding of the promotion level, and perhaps a bit of data massaging.

One such promotion level distinction, not found in many projects, is the distinction between a checked-in file and one that is ready for the next build. For example, two Updates may be co-dependent and completed by different developers.  The first may finish his/her work early while the second requires a few more days.  In some shops, the first developer simply keeps the files for the Update in the workspace until the second update is ready.  This causes the need for more parallel checkouts because the files are sitting in the workspace for an extended period of time.  In other shops the files are checked in to a new branch, with the Update identifier as a tag, while awaiting the work of the other developer.  In this scenario, at least the files are visible to other users, although branching, and subsequent merging, is required, even though it may be trivial.

Introducing a "ready" promotion level in-between the "checked in" and "in the build" states (a promotion level is really just a state of the object), allows the code to be checked in without having to create a separate branch and without the danger that it will get pulled into the build until the "ready" status is achieved.  In the mean time, it