Projektpfade eingeben
Wenn Sie ein Windchill RV&S Konfigurationsverwaltungsprojekt im Feld Projekt eingeben, können Sie den Projektpfad und -namen mit einer flachen oder schlüsselwortbasierten Zeichenfolge angeben.
Wenn Sie einen Projektpfad und -namen mit einer flachen Zeichenfolge angeben, treten Beschränkungen und eventuelle Mehrdeutigkeiten auf. Beim Spezifizieren eines Projektpfads und -namens mit einer schlüsselwortbasierten Zeichenfolge können Sie das richtige Projekt eindeutig angeben, auch wenn es in mehr als einer Konfiguration vorhanden ist. Mit einer Schlüsselwortzeichenfolge können Sie in der Konfigurationsbaumstruktur navigieren, zuerst zu einem registrierten Projekt, dann entsprechend der Projekthierarchie zu Unterprojekten und wahlweise zur gewünschten Varianten- oder Build-Hierarchie springen, sobald diese im Konfigurationspfad verfügbar ist.
|
|
Es gibt Beschränkungen zu den Sprungtypen zu Unterprojekten mit anderen Konfigurationen. Weitere Informationen finden Sie unter Regeln für Sprünge. |
Sie können die folgenden Schlüsselwörter verwenden, um einen Projektpfad und -namen anzugeben:
• # So geben Sie ein Projekt oder Unterprojekt in einer ordnungsgemäß gebildeten Projektbaumstruktur an
• #n So geben Sie ein normales Projekt an
• #p So geben Sie ein Projekt auf oberster Ebene an, das nicht auf project.pj endet
• #s So geben Sie ein Unterprojekt an, das nicht auf project.pj endet
• #d So geben Sie den Entwicklungspfadnamen an
• #b So geben Sie Nummer, Beschriftung oder Symbol der Projektrevision an
|
|
• Die Reihenfolge der Schlüsselwörter ist wichtig. Schlüsselwörter werden von links nach rechts verarbeitet, um die Projektspezifikation zu erstellen.
• Wenn Sie die Symbole # oder = in einem Schlüsselwortwert angeben müssen, geben Sie das Symbol zweimal an (## bzw. ==).
• Beim Spezifizieren eines Varianten-Unterprojekts müssen Sie den Pfad vom Stamm des Variantenprojekts aus angeben (das Projekt, durch das der Entwicklungspfad erstellt wurde).
|
Beispielsweise gilt folgendes Projektsetup:
/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)
Das Unterprojekt shared_code/project.pj wird mit /projects/libra/project.pj gemeinsam genutzt, und das Unterprojekt source_code/project.pj enthält die benachbarten Unterprojekte project.pj und project2.pj, die beide das Unterprojekt colocated.pj gemeinsam nutzen.
Sie können eine schlüsselwortbasierte Zeichenfolge verwenden, um auf die drei anderen Konfigurationen desselben Projekts zu verweisen:
#/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
Weitere Informationen zum Verwenden einer schlüsselwortbasierten Zeichenfolge finden Sie auf der Seite "Optionen" im CLI-Man-Pages.
Regeln für Sprünge
Wenn Sie zu einer bestimmten Konfiguration in einem Projektpfad springen, gelten die folgenden Regeln:
• Von einem Build-Projekt können Sie nicht zu einem anderen Ziel springen.
• Von einem normalen Projekt können Sie nur zu einer Variante springen, wenn es der Stamm der Variante ist (das Projekt, durch das der Entwicklungspfad erstellt wurde).
• Sie können nicht zu einer Variante springen, wenn sich diese von der nächsthöheren Variante in der Projekthierarchie unterscheidet (sofern es eine höhere Variante gibt). Wenn keine Unterprojekte als Varianten in der Hierarchie konfiguriert wurden, ist die nächste Variante die Variante des Projekts der obersten Ebene. Wenn mindestens ein Unterprojekt in der Hierarchie als Variante konfiguriert ist, ist die nächste Variante die Variante des niedrigsten konfigurierten Unterprojekts. Das schließt die Variante des Unterprojekts nicht ein, zu dem gesprungen werden soll, wenn es zu diesem Zeitpunkt als Variante konfiguriert wird.
Die letzten zwei Regeln werden basierend auf dem Typ des Eltern-Projekts überprüft.
|
|
Sie können stets zur aktuellen Konfiguration eines Unterprojekts springen, auch entgegen den oben aufgelisteten Regeln.
|
Beispiel: Zu Varianten springen
Beispielsweise gilt folgendes Projektsetup:
/projects/aurora/source_code/savings_tool/project.pj
source_code ist ein Unterprojekt, das jetzt als beta_variant konfiguriert ist, und savings_tool ist ein gemeinsam genutztes Unterprojekt, das jetzt als "normal" konfiguriert ist. Folgender Sprung ist zulässig:
#/projects/aurora#source_code/savings_tool#d=beta_variant
Folgender Sprung ist unzulässig:
#/projects/aurora#source_code/savings_tool#d=prod_variant
Sie können einen Sprung zu beta_variant vom Unterprojekt savings_tool angeben, da es sich um die gleiche Variante wie für source_code handelt, und da es als gemeinsam genutztes Unterprojekt als lokaler Variantenstamm akzeptiert wird (das Konfigurationsverwaltungsprojekt, durch das der Entwicklungspfad erstellt wurde). Sie können nicht zu prod_variant springen, da es sich von der Variante von source_code unterscheidet.
