Server Configuration > Server Policies for SCM > Entering Project Paths
 
Entering Project Paths
When you enter an Integrity Lifecycle Manager configuration management project in a Project field, or when you define subproject scope for a Sandbox using a Sandbox-relative configuration path, you can specify the path and name using a flat string or a keyword-based string.
When you specify a project or configuration path and name using a flat string, there are limitations and potential ambiguities. Using a keyword-based string, you can clearly specify the correct project, even when it exists in more than one configuration. A keyword-string enables you to navigate into the configuration tree, starting with a registered project, follow the project hierarchy into subprojects, and optionally jump 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 symbol 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).
Specifying a Sandbox-relative configuration path using a keyword-based string applies only to Sandbox commands, and only when specifying subproject scope. The keywords #b, #d, or #n are not supported when using keywords to specify a Sandbox-relative path.
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)
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
For more details on using a keyword-based string, see the options page of the CLI man pages.
Rules for Jumps
Example: Jumping to Variants