si createdevpath
creates a development path
Synopsis
si createdevpath [--projectRevision=rev] [--devpath=path] [(-P project|--project=project)] [--onExistingDevpath=[confirm|sharedevpath|cancel]] [--creationMethod=[full|extendable|build]] [--onLiveConfiguration=[retainLive|createVariant] [--[no]failOnAmbiguousProject] [(-S sandbox|--sandbox=sandbox)] [--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]]
Description
si createdevpath creates a development path from a specific project checkpoint.
A development path is an identifier given to a new branch of software development. Changes made through the new development path are kept separate from the main development trunk unless you choose to merge them later.
Once you have created a development path, you can open and work in a project on the development path by opening a variant Sandbox using the
si createsandbox command.
Integrity Lifecycle Manager allows multiple developers to point to the same development path, each using their own variant Sandbox. In the variant Sandbox, you can see the current state of the project along the development path and the changes made by other developers using it.
By default, when a development path is created for a project, it is also created for all subprojects, reserving the assigned name as a unique identifier and ensuring no two paths can share the same name. The project is also automatically checkpointed when a development path is created
Branching projects is useful for:
• extracting and building from previous versions of a project
• building customized versions of a product
• performing branch development work
• performing post-release maintenance
• fixing defects in previous versions of the product
• testing new features outside of the main development path
• experimenting with research that does not affect regular development
There are main models to follow when branching projects:
• release based branching
• project based branching
For more information on these models, see the Integrity Lifecycle Manager Help Center.
|
|
You can branch members instead of projects by specifying --branch when checking files in. You still may have to merge changes, but the development path remains the same. For details on branching members, see the si ci reference page. |
The following is an example for creating a development path:
si createdevpath --project=c:/Aurora_Program/bin/Libra/project.pj --projectRevision=1.3 --devpath=DevStream2
Managing an Existing Development Path
When creating a development path with the same name as an existing development path on a subproject in the target project, the default behavior is to use the existing development path in the subproject project and silently add it into the new top-level development path. To let you choose the appropriate course of action, specify the --onExistingDevpath=[confirm|sharedevpath|cancel] option. For example, if you incorrectly created a development path on a subproject and not the intended top-level project, you can choose to use the existing development path on the top-level project.
|
|
• While you can configure the si createdevpath --onExistingDevpath=[confirm|sharedevpath|cancel] preferences from the Integrity Lifecycle Manager Client, an administrator can override and enforce a specific preference on the Integrity Lifecycle Manager Server.
• If the existing development path cannot be used with the target project, an error message appears, displaying the configuration path that is incompatible with the target project.
• If specifying confirm, you cannot specify to create an extendable development path (an error is returned).
|
Configuration Options For Live (Non-Build) Subprojects
Depending on your software development needs, a project and its subprojects may be configured similarly or differently. For example, a project and its subprojects may use the same main development path for a major release. In another example, a project and several of its subprojects may use a development path branched off the main development path for a service pack release; however, one subproject may be configured as a build subproject because it contains a set of shared libraries at a specific version that you do not want to change.
When creating a development path for a project, the default behavior is to create a new development path for the project and any subprojects that are configured the same as the parent project. For example, if a parent project and its subprojects are on the mainline development path or they are on a variant development path, a new development path is created for the parent project and its subprojects. This is corresponds to setting --creationMethod=full and --onLiveConfiguration=retainLive.
If a project contains subprojects that are configured differently than the parent project, the default behavior is to retain the current configuration for those subprojects. For example, if a parent project contains one subproject that uses the same development path as the parent, but another subproject uses a different development path than the parent, a new development path is created for the parent and the subproject on the same development path as the parent. The subproject that uses a different development path than the parent remains untouched, retaining its existing development path.
During the course of development, you may decide that any subprojects that are subject to change (subprojects configured as normal or variant, also known as live subprojects) need to be on the same new development path as the parent project or be configured as build subprojects so that they remain at a specific version, based on the configuration as of the checkpoint that the new development path is created from. For example, if you have a project that is on an existing development path and contains one subproject using the same development path and another subproject using a different development path, you can choose to create a new development path for the parent project and both subprojects. In another example, if a parent project is on an existing development path and contains one subproject that is on a different development path and another subproject that is a build subproject, you can choose to create a new development path for the parent project and configure the existing variant subproject as a build subproject; the existing build subproject remains untouched.
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.
• --devpath=path
identifies the name of the new development path.
|
|
The following characters are not permitted in a development path name:
• \n
• \r
• \t
• :
• [', ']
• #
• ISO control characters
• Ignorable characters in a Java or Unicode identifier
• Any other characters that your administrator has identified using the mksis.si.restrictedCharsForDevpathName property. For more information, see "Source Configuration Properties in the Database" in the Integrity Lifecycle Manager Help Center.
|
• --projectRevision=rev
identifies the checkpointed revision number to create the variant against.
• --onExistingDevpath=[confirm|sharedevpath|cancel]
specifies the appropriate course of action if the development path has the same name as an existing development path on a subproject in the target project.
◦ confirm prompts you to confirm using the existing development path for the target project. Integrity Lifecycle Manager displays the total number of subprojects with the same development path name and the names of the first 10 subprojects.
◦ sharedevpath uses the existing development path for the target project.
◦ cancel means cancel the operation and choose a new development path name.
• --creationMethod=[full|extendable|build]
specifies the way to create the development path.
◦ full creates a full development path in a single locking transaction.
◦ extendable creates an extendable development path. For information on extendable development paths, see the documentation for
si extenddevpath.
◦ build creates a development path at the root of a project hierarchy. All subprojects are explicitly configured as build and marked as non-extendable.
• --onLiveConfiguration=[retainLive|createVariant
specifies how to treat live subprojects. Live configurations are subprojects that are configured to either normal or to a variant other than the variant you are creating.
◦ retainLive specifies that the project tree retain its existing live configuration. All live configurations remain live in the new development path.
◦ createVariant creates the development path on all previously live subprojects.
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
