A revised baseline is created by applying requests to a previous baseline. Applying the requests affects the original baseline based on the relationship of the item revision to the request. There are two groups of requests that you can use to revise a baseline:
Update baseline using, requests used to update the baseline with item revisions
Remove from baseline, requests used to remove item revisions from the baseline
When creating a revised baseline using the Update baseline using list, modifications to the original baseline, based on the relationship of the item revisions to the requests, are made as follows:
Requests with item revisions that are related as Affected only will have no effect on the new baseline.
Requests with item revisions that are related to them as Affected and In Response will have any previous versions of those same items already in the original baseline replaced with the In Response revision, regardless of whether or not the revision of the item in the original baseline matches the revision related to the request as Affected.
Requests with item revisions that are related as Affected and In Response where the Item ID of the In Response item is not already in the original baseline at any revision will have the In Response revision added to the revised baseline.
Requests with In Response revisions only will have the In Response revisions added to the baseline.
If a request relates to refactoring changes those changes are processed as described in Project Structure Changes.
When creating a revised baseline using the Remove from baseline list, any item revisions in the original baseline that are related as Affected to the requests will be removed from the new baseline.
If two or more item revisions are on different branches, Dimensions CM issues a warning and processing continues without changing the revision of that item in the baseline.
For example, if you create a new baseline for a maintenance release from the main development branch, it may contain unwanted features and untested code. However, if you revise a previous release baseline, the only changes introduced are those contained in the requests included in the baseline.
Every revised baseline has only 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 revised baseline. Because the contents of this baseline are no longer determined directly by the rules of a baseline template, its template ID is REVISED.
When you create a revised baseline, it will include change information for all project structure or refactoring changes related to the specified requests. When you perform actions that involve refactoring, such as renaming a project folder, or exporting an item to the project, and you specify a request in the Track changes with request(s) field, those changes will be recorded against that request. Specifying those requests in the Update baseline using list will result in the changes being applied to the revised baseline.
When project structure change control is enabled, the following changes to project structure are recorded against change requests:
Change |
Description |
---|---|
Item addition and removal |
An item revision is added or removed from a project. The change is recorded in one of the following:
|
Item rename |
An item is renamed or moved in the project structure. |
Directory creation, deletion, and rename |
A directory is created, deleted, or renamed in the project structure. |
When you create a revised baseline, the new baseline will include all the structural changes tracked by the specified requests. It is important to note that the structural changes will only be applied if they relate to the project whose context matches that within which the baseline is being revised. Structural changes outside of this context will be ignored.
When you create a revised baseline, the operation interprets different types of structure changes in the following ways:
Item additions related to update requests are interpreted as new candidate items to be added to the baseline.
Item and directory renames related to update requests are interpreted as candidate changes to the baseline file/folder structure.
Item removals related to update or remove requests are interpreted as candidates for removal from the new baseline.
Directory removals related to update or remove requests are interpreted as candidate changes to the baseline structure.
For more information on revised baselines, see the Dimensions CM User’s Guide.
When you create a revised baseline:
The operation ignores directory or item removals if the items or directories were not in the original baseline or have not since been added in the context of a structure change.
All structure changes are performed in their original sequence to ensure integrity is maintained when item and directory renames are interleaved.
If the operation encounters a rename or removal change to a directory path, it avoids renaming or removing the wrong directory by ensuring that there have been no directory additions or renames to the same path since the baseline was created. For example, if:
The original baseline included the directory "/source".
The original "/source" directory has since been deleted.
A new directory named "/source" has been added, with different content.
This new /source directory was renamed to "/files".
Then the Create Revised Baseline operation detects that the original "/source" directory is not the same as the new /source directory, and fails with an error.
Related Topics