CM: THE NEXT GENERATION of ALM Tool

or file you want to remove, or to which you want to add a file/component, and select the appropriate operation.  Or drag and drop files and directories within the tree.  CM+ prompts to associate the operation with the correct user Update.  Then those operations move around with that Update.  Add such an update to your context (or use one that includes it) and you'll see the structural changes; remove it and they'll be gone.

7. Configurations, Baselines and Builds
Each combination of product, stream, and promotion level defines a (dynamic) configuration of the product for a stream.  As Updates are promoted, these configurations change (i.e. they are rule based).  An align operation, typically performed by the CM manager, allows the rule-based configuration to be transformed into a static list of file/directory revisions.  As necessary, if the latest directory revision is frozen, a new directory revision is created to reflect changes within each directory. At some point an aligned configuration is frozen (i.e. it becomes a Baseline).  The configuration may be aligned multiple times (e.g. after some last minute features) before it is frozen. The Baseline is simply the revision of the top-level item that was frozen.  All future changes will go into a later revision of the configuration.  There is no need for developers to checkout or configure a directory.

Fig. 4 - Hierarchical Baseline definition, comparing a new release (changes shaded) with an older release.

Manage the superset, build the subset. If you have a number of variant builds for each release, don't create a baseline for each that has to be individually managed. Instead, create a baseline for the superset of all files for the release, and create build records in terms of that baseline.  This is the recommended CM+ operation.  A Baseline is a hierarchical decomposition of specific revisions of each directory component within the product tree - a frozen configuration.   

A Build definition takes a Baseline, or a subset (e.g. a sub-tree), possibly adds some variant information (e.g. English, Enterprise Edition), and then adds Updates to be applied on top of the baseline (e.g. a couple of bug fixes done after the Baseline was frozen).  This fully defines a set of revisions but in a very different manner - one that is a lot easier to compare and understand than two sets of file revision enumerations.

In CM+, baselines are identified by the revision of the top-level directory (i.e. the product root node) of the baseline, and builds are specified by a (possibly auto-generated) name.  Typically, a series of Builds proceed from a Baseline as Updates are checked in and new builds required (e.g. nightly builds).  Most larger shops will automate this process by kicking off a Build definition process, and subsequent build operation.  The build definition process, whether automated or manual, consists of the following steps:

1. Select a Product and development Stream context to work in.
2. Promote any Updates targeted for the Build (e.g. Update status moved from "ready" to "selected" for hot fixes)
3. Start the new Build definition based on either the previous Build, or on a Baseline.
4. Add the promoted Updates to the Build definition.
5. Perform a trial build and quick sanity test.  If successful freeze the Build definition. Otherwise fix issues and go to 2.

Just like a Baseline definition, a Build definition may be used to populate a workspace, establish a context view, or establish a Baseline.  Unlike a Baseline which is a Configuration that is Frozen or not (i.e. not yet a baseline), a Build has a full range of Promotion Levels through which it will pass.

8. Update