Configuring a Configuration Management Subproject
|
CLI EQUIVALENT
|
si configuresubproject
|
Once you create or add a subproject, you can modify the type to suit your needs. For example, you can change a normal subproject to a build subproject to suspend development, or you can change a variant subproject to a normal subproject to continue development on the main trunk.
For example, Jen wants the ABC Tools development team to work with revision 1.2 of amortization/project.pj, the last known stable version of the code. Jen does not want the general development team to do any further development on this release, so she configures the amortization/project.pj subproject to be a build subproject.
|
Interface
|
Procedure
|
|
GUI
|
Select Configure Subproject.
|
|
Web
|
Select > .
|
When configuring a subproject you can specify one of the following types:
• Normal configures a subproject to the working subproject on the mainline.
• Variant configures a subproject to a specific development path.
|
|
• The Variant option is unavailable if there are no available development paths.
• Deactivated development paths are not shown in the Development Path Name list.
|
• Build configures a static subproject to a specific checkpoint of the project that is used for building or testing the project, but not for further development. You can specify the checkpoint through its checkpoint number or label.
Changes Between Configurations
Any changes you make when configuring a subproject affects the project as a whole and any shared subprojects within it. Deltas reflecting these changes appear in the Project or Sandbox view. Some differences you may see include:
• Members existing in the original version and configured version of the subproject display a delta if the working revision in the Sandbox is different from the new member revision.
• Members that did not exist in the original version of the subproject, but do exist in the configured subproject, display a delta to indicate that the Sandbox does not have a working file for the new member.
• Members that existed in the original version of the subproject, but do not exist in the configured subproject, display as former members.
• Subprojects that existed as members in the original version of the subproject, but do not exist in the configured subproject, display as former subprojects.
To resolve the differences, resynchronize the subSandbox.
Configuring Shared Subprojects
When configuring shared subprojects, remember that each shared subproject is configured independently. This means that when you configure a shared subproject, the reconfiguration does not change all instances of that subproject. For example, if the subproject tools/project.pj is shared in the two projects, Aurora/project.pj and Libra/project.pj, a change to the configuration of Aurora/tools/project.pj does not affect the configuration of Libra/tools/project.pj.
Source Integrity Standard Subprojects
Configured subprojects or frozen subprojects created in Source Integrity Standard (an earlier version of Integrity Lifecycle Manager) are detected as they are accessed by Integrity Lifecycle Manager without disrupting the operation. The format of these subprojects is retained until you change or update it to the new format by reconfiguring it.
