User Help > Grouping Files Under Version Control > Creating a Development Path
 
Creating a Development Path
CLI EQUIVALENT 
si createdevpath
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.
For example, a user group at ABC Financial requests a special version of the stock calculator software. This group wants the commission fields removed and a special commissions legal message added. The task is assigned to Chad. He must use version 1.0 of the software because it did not contain commission fields. He must then add the new legal message to this version. He begins by creating a development path and a variant Sandbox from the checkpointed 1.0 version.
Once you have created a development path, you can open and work in a variant project by opening a variant Sandbox.
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.
When a development path is created for a project, by default it is also created for all subprojects. The assigned name is reserved as a unique identifier, ensuring no two paths can have the same name. The project is also automatically checkpointed when a development path is created.
Interface
Procedure
GUI
Do one of the following:
Select a project or Sandbox and select Project > Development Path > Create.
Select File > New > Development Path. Then, select a project.
Web
Select a project and select either Project > Create Development Path or History > Create Development Path.
* 
You cannot create a development path for a project if a checkpoint is in progress on that project.
Selecting the Checkpoint to Create a Development Path From
You select the checkpoint from which to create a development path by selecting Pre-Defined Revision or Specific Revision. For Specific Revision, the most recent checkpoint is initially the default and shown in the parentheses to the right.
When Pre-Defined Revision is selected, you select one of the following revisions:
Head—Latest checkpoint on the default branch of development or on the mainline if no default is specified.
Trunk Tip—Latest checkpoint on the mainline independent of the default branch settings.
To choose the specific checkpoint from which to create the development path, you do one of the following:
Click the Revisions tab and select a checkpoint number.
Click the Labels tab and select a checkpoint label.
The display to the right of Specific Revision is updated accordingly.
You can view the development path of a checkpoint, plus any development paths branched from a checkpoint in the Project History view. In this view, you select the checkpoint and view the details panel.
For Development Path Name, you enter a name for 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.
Managing an Existing Development Path
You specify the behavior to occur if a development path with the same name as an existing development path is created on a subproject in the target project. Typically, the default behavior is to use the existing development path in the subproject’s project, silently adding it into the new top-level development path. For On Existing Development Path, you can select from the following actions:
Share Development Path—Use the existing development path for the target project.
Query User—Display a prompt to confirm the use of the existing development path for the target project. The prompt displays the total number of subprojects with the same development path name and the names of the first 10 subprojects.
Cancel—Cancels the operation so that a new development path name can be chosen. For example, assume that you incorrectly created a development path on a subproject and not the intended top-level project. You can choose to reuse the existing development path on the top-level project.
* 
You can specify the default behavior by configuring the Create Development Path command preference in the Preferences Configuration window. While you can configure the command 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. The message indicates that the configuration path is incompatible with the target project.
Configuration Options For Live (Non-Build) Subprojects in the GUI
A project and its subprojects can be configured similarly or differently, depending on your software development needs. 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, assume that a parent project and its subprojects are on either the mainline development path or a variant development path. A new development path is created for the parent project and its subprojects. This corresponds to setting Creation Method as Full and On Live Configuration to Retain the existing live configuration of the subproject.
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. Assume that a parent project contains one subproject that uses the same development path as the parent. However, it also contains another subproject that 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 development, subprojects configured as normal or variant, also known as live (non-build) subprojects, might possibly need to change. Live subprojects might 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 from which the new development path is created.
For example, assume that you have a project that is on an existing development path. This project 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.
Now assume that a parent project is on an existing development path. It 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.
To specify the way to create the development path, use the Creation Method option in the GUI. Select one of the following:
Full creates a full development path in a single locking transaction.
Extendable creates an extendable development path.
Creating an extendable development path configures all subprojects as build and marks them as extendable. For more information on extendable development paths, see Extending an Extendable Development Path.
Non-extendable with all subprojects configured as build creates a development path at the root of a project hierarchy. All subprojects are explicitly configured as build and marked as non-extendable.
To specify how to treat live subprojects, use the On Live Configuration option in the GUI. Live configurations are subprojects that are configured to either normal or to a variant other than the variant you are creating. Select one of the following:
Retain the existing live configuration of the subproject specifies that the project tree retain its existing live configuration. All live configurations remain live in the new development path. The following is an example of using this option:
Create the development path on the subproject creates the development path on all previously live subprojects. The following is an example of using this option:
Configuration Options For Live (Non-Build) Subprojects in the Web
The Configuration Management Web interface uses the legacy option Resulting Subproject Configuration. Select one of the following:
On development path except explicitly configured subprojects (Legacy) is equivalent to simultaneously setting Creation Method to Full and On Live Configuration to Retain the existing live configuration of the subproject in the GUI. For more information, see the descriptions for those options.
On development path is equivalent to simultaneously setting Creation Method to Full and On Live Configuration to Create the development path on the subproject in the GUI. For more information, see the descriptions for those options.
Lightweight (Build) is equivalent to setting Creation Method to Non-extendable with all subprojects configured as build in the GUI. For more information, see the description for that option.