A merged baseline is created by selecting a top level design part, and specifying two or more existing baselines from which item revisions are to be included. Each input baseline must be either a release baseline or an earlier merged or revised baseline. All the baselines must reference the same product that will be specified for the new baseline.
The baselines in a list are considered in the order specified in that list. Every item in each baseline is checked and ignored if:
it is not in the new baseline's project or design part structure.
any revision of the same item has already been added to the new baseline.
If these checks are passed, the item revision is added to the new baseline. This continues until all items in all the baselines in the list have been dealt with.
This processing rule means that, for any item in the merged baseline, the revision added will be the one found in the first baseline in the list that contains that item. Therefore, in order to obtain a merged baseline with satisfactory contents, you would normally list the input baselines by creation date, in ascending order (the most recent baselines first and the oldest last).
A merged baseline typically has the same scope, or list of design parts, as the baselines used to create it. However, if you select a design part that is different from the source baselines, items that are in the source baselines that are not owned by the design part of the merged baseline are not included in the new baseline.
Every merged baseline has no more than one revision of any item, so it can be used like any other release baseline. For example, to create a test or release configuration of the product.
You can also use a revised or merged baseline to create another merged baseline. Because the contents of such a baseline are no longer determined directly by the rules of a baseline template, its template ID is MERGED.
NOTE For more information about merging baselines see CMB – Create Merged Baseline in the Command Line Reference.
Related Topics