si configuresubproject
configures a subproject's type
Synopsis
si configuresubproject [-r subproject revision|--subprojectRevision=subproject revision] [--subprojectDevelopmentPath=subproject development path name|--variant=subproject development path name] [--[no]failOnAmbiguousProject] [--type=[normal|variant|build|default]] [(-P project|--project=project)] [(-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 [--[no]imIssue] [--[no]imIssueCP]
Description
Once you have created or added 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.
 |
Any changes you make when reconfiguring a subproject affects the project as a whole and any shared subprojects. More specifically, changing the type, revision, or development path of a subproject can radically change the list of members of that subproject. After configuring a subproject, existing sandboxes whose contents were in sync with the subproject before it was configured will display deltas when you use si viewproject and si viewsandbox, reflecting the following possible differences:
• Members that exist in both the old and new version of the subproject display a delta if the working revision in the Sandbox is different from the new member revision.
• Members that are in the new version of the subproject but were not in the old version of the subproject display a "no working file" delta, indicating that the Sandbox does not have a copy of the new member yet.
• Members that were in the old version of the subproject but are not in the new version display as former members.
• Subprojects that were in the old version of the subproject but are not in the new version will display as former subprojects.
|
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.
• -r=subproject revision
• --subprojectRevision=subproject revision
specifies the checkpoint number (for build subprojects). For example, 1.5. This option is used with --type=build.
• --subprojectDevelopmentPath=subproject development path name
• --variant=subproject development path name
specifies the development path name (for variant subprojects). For example, Service_Pack3. This option is used with --type=variant.
• --type=[normal|variant|build|default]
specifies the new configuration type for the subproject.
◦ --type=normal configures the subproject to the master (non-variant) version of the subproject.
◦ --type=variant configures the subproject based upon a specific development path. The option is used with --variant=subproject development path name or --subprojectDevelopmentPath=subproject development path name.
◦ --type=build configures the subproject as a static subproject based upon a specific checkpoint of the master project that is used for building or testing the project, but not for further development. This option is used with -r subproject revision or --subprojectRevision=subproject revision.
◦ --type=default configures the subproject based on the type that is consistent with the parent project that you are adding the subproject to. For example, if you add a subproject to a normal project, the subproject is added as a normal type. For information on what the default type is, see your administrator.
• --cpid=ID
• --changePackageId=ID
identifies a change package that is notified of this action, for example, 1452:1. Note the following about using this option:
◦ 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.
• --issueId=value
specifies the issue ID that corresponds to the change package that records the changes.
• subproject
• subsandbox
specifies the subproject or sub Sandbox name to which the new configuration applies, for example, tools.pj
• --[no]imIssue
Consider the issue provided as a PTC RV&S issue.
• --[no]imIssueCP
Consider the provided change package as associated with a PTC RV&S issue.
Preferences
Using si setprefs or si viewprefs, you are able to set or view the preference keys for this command.
See Also