si movesubproject
moves a subproject between projects or between directories of a single project
Synopsis
si movesubproject [--[no]confirm] [--[no]createSubprojects] [-f] [--moveWorkingFiles=[none|members|all]] [--[no|confirm]overwrite] [--targetDevpath=value] [--targetDir=value] [--targetProject=value] [--targetSandbox=value] [(-P project|--project=project)] [--[no]failOnAmbiguousProject] [--[no]preserveCase] [(-S sandbox|--sandbox=sandbox)] [--devpath=path] [--hostname=server] [--port=number] [--password=password] [--user=name] [(-?|--usage)] [(-F file|--selectionFile=file)] [(-N|--no)] [(-Y|--yes)] [--[no]batch] [--cwd=directory] [--forceConfirm=[yes|no]] [(-g|--gui)] [--quiet] [--settingsUI=[gui|default]] [--status=[none|gui|default]] [--cpid=ID|--changePackageId=ID] [--[no|confirm]closeCP] [--issueId=value] subproject or subsandbox
Description
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.
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.
Before using si movesubproject, note the following:
• Moving subprojects between projects on different servers is not supported.
• The moved subproject inherits the project or directory ACLs from its original location. You cannot apply the ACLs from the new location to the subproject.
• 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 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.
• Deferred subproject moves are not supported.
• You can move one or more subprojects across directories within a single project.
• Moved subprojects are not displayed as shared in a Sandbox or Project view unless the subproject was shared before the move.
• 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, use the
si sharesubproject command on the subproject you want to move, followed by
si drop in the original location.
• If you move a subproject that is associated with any Integrity Lifecycle Manager issues, the issues no longer display as associated issues for the project. You must edit the Integrity Lifecycle Manager issues to associate them with the subprojects in their new locations.
• You can change the case of the subproject path name when you move the subproject in a Sandbox, for example, Test/project.pj to test/project.pj
|
|
• To correctly change the subproject 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 si applycp or si resynccp command to propagate a move subproject (path name case change) operation or drop subproject/add shared subproject in a single operation
• Before performing additional operations using the new subproject location, resynchronize the former subproject in your Sandbox.
|
The following is an example of the command syntax:
si movesubproject --confirm --targetProject=c:/Alias_Program/Capricorn/project.pj c:/Aurora_Program/bin/Libra/project.pj
Options
This command takes the universal options available to all
si commands, as well as some general options. See the
options reference page for descriptions.
• --[no]confirm
controls whether to confirm the move before proceeding.
• --[no]createSubprojects
controls whether to create subprojects in existing directories that do not contain subprojects.
• -f
force the move without confirmation.
• --moveWorkingFiles=[none|members|all]
controls whether to move existing working files in the subproject. This option is valid only if you are moving one or more subprojects from a source Sandbox to a target Sandbox.
• --[no|confirm]overwrite
controls whether to confirm before overwriting any existing working files that exist in the new location. This option is valid only if you are moving one or more subprojects from a source Sandbox to a target Sandbox.
• --targetDevpath=value
specifies the target development path (for variant projects). This is a label that was associated with a branch of the project by
si createdevpath. Paths that include spaces must be enclosed by quotes. The following characters may not be used in a development path: \n, \r, \t, :, [', '], #.
|
|
This option cannot be used if you specify a target project using a keyword string for the --targetProject option.
|
• --targetDir=value
specifies the subdirectory in the destination project or Sandbox’s directory that you want to move the subproject(s) to.
• --targetProject=value
specifies the name of the target project. For information on how to specify a project, see the
options reference page.
• --targetSandbox=value
specifies the name of the target Sandbox (can be used as a project redirector).
• --cpid=ID
• --changePackageId=ID
identifies a change package that is notified of this action, for example, 1452:1.
|
|
• This option can only be specified if change packages are enabled.
• If the integration is enabled, but it is not mandatory to specify a change package, or if no change package is applicable, you can specify --changePackageId=:none
• The next time you are prompted for a change package ID, the last used change package ID is displayed by default, if :none was specified or at least one change package was successfully updated from the last operation.
|
• --[no|confirm]closeCP
closes the change package after command completion.
• --[no]preserveCase
specifies that the destination directory uses the same case that exists on the file system. By default, --preserveCase is specified. To change the case of the subproject path name, type the new subdirectory name using the --targetDir=value option and specify --[no]preserveCase. In a Project, this option is not available and the subproject path name is changed to the exact name you type.
• --issueId=value
specifies the issue ID that corresponds to the change package that records the changes.
• subproject or subsandbox
identifies a subproject or sub Sandbox to move; use spaces to specify more than one subproject
Diagnostics
See the
diagnostics reference page for possible exit status values.
Preferences
Using
si setprefs or
si viewprefs, you are able to set or view the preference keys for this command.
See Also
