Borland® StarTeam® 2006 - Borland Technical Publications

Durch verschobene Objekte erstellte Referenzen
Wenn Sie einen Ordner oder ein Element von einem Speicherort an einen anderen Speicherort in derselben Ansicht
verschieben, löscht StarTeam das Objekt am alten Speicherort und fügt ihn am neuen Speicherort wieder ein. Dieser
Vorgang kann jedoch Auswirkungen auf die übergeordnete und die untergeordnete Ansicht haben, wenn diese
unverankert sind. Der Grund dafür ist, dass die Kopie nur in der aktuellen Ansicht an der ursprünglichen Position
gelöscht wird. Daher kann es vorkommen, dass in der übergeordneten und der untergeordneten Ansicht anstelle
einer Referenz auf die neue Position zwei Referenzen angezeigt werden (eine auf die alte Position und eine auf die
neue Position).
Beispiele für Referenzhierarchien
Angenommen, Sie verschieben in einer Ansicht ohne verzweigte Unteransichten die Datei timeout.doc aus dem
Ordner Marketing Documents in den Ordner Timeout.
Die folgenden zwei Beispiele zeigen die Referenzen auf diese Datei vor und nach dem Verschiebevorgang. Die
Anzahl der Referenzen bleibt gleich. Der Pfad zur Datei hat sich geändert. Die Datei wurde an ihrer ursprünglichen
Position gelöscht und an der neuen Position eingefügt.
Vor dem Verschieben: Big Product::Big Product::Big Product\Marketing Documents::timeout.doc, 1.0
Nach dem Verschieben: Big Product::Big Product::Big Product\Source Code\Timeout::timeout.doc, 1.0
Angenommen, diese Ansicht hat eine untergeordnete Ansicht, die bei bestehender Verbindung zur übergeordneten
Ansicht erstellt wurde (die untergeordnete Ansicht ist also verzweigt und unverankert). Wenn die verschobene Datei
in der untergeordneten Ansicht noch nicht verzweigt ist, wird sie an der alten Position nicht gelöscht, weil Sie sie
möglicherweise dort noch benötigen. Sie wird jedoch an der neuen Position eingefügt, weil der Vorgang als Änderung
der übergeordneten Ansicht betrachtet wird, die in der untergeordneten Ansicht wiedergegeben werden muss.
Für die Datei gibt es in der übergeordneten Ansicht nur eine Referenz, in der untergeordneten Ansicht gibt es zwei.
♦ Big Product::Big Product::Big Product\Source Code\Timeout::timeout.doc, 1.0
♦ ... Big Product::Big Product\branched floating::Big Product\Marketing Documents::timeout.doc, 1.0
♦ Big Product::Big Product\branched floating::Big Product\Source Code\Timeout::timeout.doc, 1.0
Einige StarTeam-Benutzer sortieren Elemente mithilfe von Ordnern. Es kann beispielsweise sein, dass sie Ordner
in einer Ansicht erstellen, um Änderungsanforderungen anhand folgender Kriterien einzuteilen:
♦ Sie werden definitiv in die nächste Version aufgenommen
♦ Sie werden für die nächste Version geprüft (zeitabhängig)
Änderungsanforderungen, die diese Kriterien erfüllen, werden in der Regel vom Stammordner in den
entsprechenden Ordner verschoben oder später neu sortiert und von einem zum anderen Ordner verschoben. Dies
erleichtert in der aktuellen Ansicht die Arbeit, kann aber in einer über- oder untergeordneten Ansicht zu vielen
Referenzen führen. Bei einer tief verzweigten Hierarchie können folglich alle möglichen über- und untergeordneten
Ansichten betroffen sein. Daher sollte man bei einer solchen Vorgehensweise untergeordnete Ansichten erstellen,
die verankert sind.
Frei platzierbar nach oben und unten in der Ansichtshierarchie
Wenn die Ansichtshierarchie weit verzweigt ist (d. h. wenn die Stammansicht über mehrere Ebenen von
Unterordnern verfügt), kann die Verwendung von unverankerten Verzweigungsansichten sehr unübersichtlich sein.
140