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
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
Preferences
Using
si setprefs or
si viewprefs, you are able to set or view the preference keys for this command.
See Also
• Commands:
si addsubproject,
si checkpoint,
si createproject,
si createsandbox,
si createsubproject,
si drop,
si dropproject,
si projectinfo,
si projects,
si sharesubproject,
si movesubproject,
si viewproject
