Use this operation when a baseline is no longer required.
PRIVILEGES Delete Baseline
You cannot delete a baseline if:
it has been used to make a release, unless you delete the release first.
it has been used to create an archive unless you retrieve the archive first. For more information, see the System Administration Guide.
it is currently promoted beyond the first stage in the GSL.
CAUTION! To delete multiple baseline at the same time, use a Dimensions CM command file—this guarantees that each baseline is deleted in turn.
To delete a baseline:
Select the baseline.
Select Baseline | Delete.
In the Delete Baseline dialog box, verify that you have selected the correct baseline, and click the OK button.
Check your Dimensions CM server email for any error messages resulting from this operation.
Related Topics
Baseline consistency checks enforce additional verifications on the requests that are used to create a revised baseline (CRB) or a request template baseline (CBL). These checks ensure that:
The requests used to create a new baseline provide a complete set of changes.
Any dependent changes are not missing.
The changes have been fully implemented.
To enable baseline consistency checks on your Dimensions CM server installation:
Add the following variable to the configuration file %DM_ROOT%\dm.cfg on the server:
DM_ENABLE_BASELINECHECKS Y
Restart the Dimensions listener.
When a new revised baseline or request-driven baseline is created, the checks described below are run to validate the consistency of the changes used to create the baseline.
To be accepted for use, any requests that are provided as an input when a new baseline is created must be at a frozen or closed state. Any requests that are still under work or being tested are detected and rejected.
Any requests that are provided as an input when a baseline is created must be one of the following:
Related to the project or stream from which the baseline command is being run.
Not be related to any project or stream.
Requests related to a different project or stream are invalid and will be rejected.
If you attempt to create a new baseline using a request that has already contributed content to a previous baseline, that request is rejected. This check, and others described below, consider the baseline being created as well as the chain of baselines that led to the current one.
For example, consider the following scenario:
The creation of BLN003 fails because the consistency checks find that CR_21 was used in a previous baseline in the chain of baselines that leads to the one being revised (BLN003).
To ensure that the request list represents a consistent and complete set of changes, the consistency checker validates the requests and their items against the following criteria to check that there are no requests missing:
For each request specified, all the related items (in response to, affected or as a result of refactoring) are examined to determine if they, or any of their predecessors, are related to other requests not already specified in the create baseline command.
If any of those requests refer to items revisions that have not already been included in the baseline, or any of its previous baselines, the requests are displayed and the command fails.
For every item being included, any changes that occurred after the latest change related to any specified request are ignored. For example, if a file was modified on Monday against CR_2 and renamed on Tuesday against CR_3 and you attempt to revise a baseline using CR_2, the rename (which occurred later against CR_3) is not included.
To ensure that only relevant items are considered in the consistency check, the following additional criteria are used to filter out any items that are irrelevant:
Only those item revisions that are present in the project or stream against which the baseline command is being run are considered. Items that are not present are ignored.
If a revision of an item is already in the baseline being revised, or any baseline in the chain that led to the one being revised, that revision and all its predecessors are filtered out. Only items that have never been in any of the baselines, or had revisions subsequently created, are considered.
Items that are not in the baseline being revised, or any baseline on the chain that led to the one being revised, and are not present in the project or stream against which the baseline command is being run, are ignored.
To override any issues identified by the consistency checks and to force the baseline to be created, add the /FORCE qualifier to the command that you submit. This qualifier generates warnings for consistency checks that are violated, however the baseline is created. Only users with the privilege that allows them to override process checks can run this command.
The change made to file2 (when a change was also made to file1) will be missing unless CR_10 is included. The consistency checks warns that the baseline cannot be created only using CR_11 as it will be missing the dependent change made using CR_10.
To get a consistent set of changes the new baseline should be created with reference to CR_22 and CR_23. If you run the following create revised baseline command:
CRB BL003 /BASELINE1=BL002 /UPDATE_CHDOC=CR_23
the consistency checks will detect that request CR_22 is missing and the command will fail.
If you re-run the baseline command and specify CR_22 and CR_23, the baseline will be created successfully because the changes referred to by CR_22 (on which CR_23 is dependent) are now included.
Web client
Select the Automation or Baseline tab.
Select a baseline.
On the toolbar do one of the following:
Baseline tab: select More | Open in SDA
Automation tab: select Open in SDA
Desktop client
In a content window select any baseline.
From the Baseline menu select Open in SDA.