Entering Project Paths
When you enter a PTC RV&S configuration management project in a Project field, you can specify the project path and name using a flat string or a keyword-based string.
When you specify a project path and name using a flat string, there are limitations and potential ambiguities. When you specify a project path and name using a keyword-based string, you can clearly specify the correct project, even it exists in more than one configuration. Using a keyword-string enables you to navigate into the configuration tree, starting with a registered project, following the project hierarchy into subprojects, and optionally jumping into the desired variant or build hierarchy as soon as it is available in the configuration path.
 |
There are limitations to the types of jumps you can make to subprojects with different configurations. For more information, see Rules for Jumps.
|
You can use the following keywords to specify a project path and name:
• # to specify a project or subproject in a well-formed project tree
• #n to specify a normal project
• #p to specify a top-level project that does not end with project.pj
• #s to specify a subproject that does not end with project.pj
• #d to specify the development path name
• #b to specify the number, label, or symbolic of the project revision
|
|
• The order of the keywords is important. Keywords are processed from left to right to build the project specification.
• If you need to specify a # or = symbol in a keyword value, specify the symbol twice (## or ==).
• If you are specifying a variant subproject, you must specify its path starting at the root of the variant project (the project through which the development path was created).
|
For example, if you had the following project setup:
/projects/aurora/project.pj (project)
shared_code/project.pj (shared subproject)
source_code/project.pj (subproject)
colocated.pj (co-located project)
/projects/libra/project.pj (project)
source_code/project.pj (subproject)
colocated.pj (co-located project)
/project/libra/project.pj (shared subproject)
source_code/project2.pj (subproject)
colocated.pj (co-located project)
shared_code/project.pj (shared subproject)
source_code/project.pj (subproject)
colocated.pj (co-located project)
/projects/libra/project.pj (project)
source_code/project.pj (subproject)
colocated.pj (co-located project)
/project/libra/project.pj (shared subproject)
source_code/project2.pj (subproject)
colocated.pj (co-located project)
where subproject shared_code/project.pj is shared with /projects/libra/project.pj, and where subproject source_code/project.pj contains co-located subprojects project.pj and project2.pj, which both share subproject colocated.pj.
You could use a keyword-based string to point to the three different configurations of the same project:
#/projects/aurora#shared_code/source_code/project.pj#s=colocated.pj
#/projects/libra#source_code/project.pj#s=colocated.pj
#/projects/libra#s=source_code/project2.pj#s=colocated.pj
#/projects/libra#source_code/project.pj#s=colocated.pj
#/projects/libra#s=source_code/project2.pj#s=colocated.pj
For more details on using a keyword-based string, see the options page of the CLI man pages.
Rules for Jumps
When jumping to a specific configuration in a project path, the following rules apply:
• You cannot jump anywhere from a build project.
• You can jump from a normal project to a variant only if it is the root of the variant (the project through which the development path was created).
• You cannot jump to a variant if it differs from the closest variant higher in the project hierarchy (if there is a higher variant). When no subprojects are configured as variants in the hierarchy, the closest variant is the variant of the top-level project. When at least one subproject in the hierarchy is configured as a variant, the closest variant is the variant of the lowest configured subproject. This does not include the variant of the subproject on which the jump is specified, if it is currently configured as a variant.
The last two rules are verified based on the type of the parent project.
|
|
You can always jump to the current configuration of a subproject, even if it violates the rules listed above.
|
Example: Jumping to Variants
If you had the following project setup:
/projects/aurora/source_code/savings_tool/project.pj
where source_code is a subproject currently configured as beta_variant and savings_tool is a shared subproject currently configured as normal. The following jump would be allowed:
#/projects/aurora#source_code/savings_tool#d=beta_variant
The following jump would not be allowed:
#/projects/aurora#source_code/savings_tool#d=prod_variant
You can specify a jump to beta_variant from the subproject savings_tool because it is the same as the variant for source_code, and because as a shared subproject it is accepted as the local variant root (the configuration management project through which the development path was created). You cannot jump to prod_variant because it is different than the variant of source_code.