Moving a Configuration Management Subproject

To meet the needs of changing project configurations, you can move one or more subprojects and all of its members and sub-subprojects between projects, and/or directories in a single project, or variants of the same project on the same Integrity Lifecycle Manager server.

For example, the size of the documentation set for the ABC Financial toolkit has increased significantly since the last release. To reduce the size of the toolkit installer, product management wants the documentation available from the CD browser only. Michelle moves the documentation.pj subproject from the toolkit.pj project to the cd_browser.pj project.

When a subproject is moved, it behaves like a shared subproject. The subproject in the new location continues to be backed by the underlying subproject in the old location, and the path and name of the subproject file in the repository remains the same. Any external references (ACL names, event triggers, policy statements) to the moved subproject continue to work because they are based on the subproject’s original name; however, a subproject that is moved into a new project hierarchy continues to inherit ACLs from its original hierarchy and not from the new parent project. The moved subproject also retains its configuration type (normal, variant, build). If you are moving multiple subprojects, any common directory prefix shared by the subprojects is automatically removed during the move.

You can also move a subproject by dragging it onto a project, sandbox, subproject, sub-sandbox, or directory node in the active Project or Sandbox view, or onto an adjacent open Project or Sandbox view. The drag-and-drop action initiates the Move Subproject Wizard, summarizing the details of the move.

You can use the move subproject action to rename a subproject. To do so, select the current parent of the subproject as the destination project, and enter the new name for the subproject as the subdirectory of the destination sandbox directory. You can also perform this task using the CLI.

• The path and name of the subproject file in the repository is permanently reserved. If you attempt to create a new subproject using the moved subproject’s original path and name in the repository, you are prompted to add the existing subproject. If you answer no, the create subproject operation exits without providing you with the option of creating a subproject with a different path and name.

• When you move one or more subprojects, you cannot co-locate subprojects in the same directory. If you want to co-locate an existing subproject with another subproject, perform an Add Subproject or Share Subproject operation to share it to the new location, and then perform a Drop Subproject operation in the original location.

• If you move a subproject that is associated with any Integrity Lifecycle Manager items, the items no longer display on the Associated Items tab for the project. You must open the Integrity Lifecycle Manager items and associate them with the subprojects in their new locations.

• If you are typing in or selecting a destination project or Sandbox instead of using the default, and you are moving the subproject to a variant or build subproject, initially only enter the path and name of the root project. You specify the subproject later in the procedure. When specifying the subproject, there are rules that control what project configuration you can jump to. If your selection breaks any of the rules, you cannot move the subproject.

When specifying a destination directory in a Sandbox, the Preserve case on filesystem option is enabled by default, ensuring that the specified destination directory uses the same case that exists on the file system. To change the case of the subproject path name, type the new Subdirectory Name and disable the Preserve case on filesystem option. In a Project view, the Preserve case on filesystem option does not appear and the subproject path name is changed to the exact name you type.

• To correctly change the path name, the subproject directory and any members in it must exist on the disk containing the Sandbox. This is useful for correcting typing errors in the path name.

• You cannot change the case of the subproject path name with transactional change packages and/or Change Package Reviews enabled. If transactional change packages and/or Change Package Reviews are enabled, drop the subproject in a change package, manually change the case of the subproject path name, and then use a new change package to add the subproject as a shared subproject.

• You cannot use the Apply CP or Resync CP command to propagate a change package where the capitalization of a subproject name is changed (where letters in the subproject name have been changed to be upper- or lower-case). This includes:

◦ Performing a move subproject operation where the location and subproject name remains the same, but the case (capitalization) of the name has changed

◦ Performing a drop subproject operation and add subproject operation where the subproject is added back with the same name, but with different case (capitalization)

• Before performing additional operations using the new subproject location, resynchronize the former subproject in your sandbox.