Etikettenschwindel? – Labels im TFS

Gerade für frühere Visual-SourceSafe-Benutzer ist das Labeling im TFS evtl. missverständlich. War doch ein Label im Visual-SourceSafe ein “benannter Zeitpunkt”, der auch in der Dateihistorie angezeigt wurde. Ganz anders und mächtiger im TFS. Doch mit großer Macht kommt große Verantwortung. Und für alle Verantwortlichen soll dieser Blogeintrag das Labeling im TFS verständlicher machen.

Im TFS werden Labels nämlich nicht in der Dateihistorie angezeigt. Wie kommt das? Im TFS ist ein Label eine Zuordnung von versionierten Elementen zu Versionen. D.h. ein Label enthält eine dedizierte Menge von Verzeichnissen und Dateien in jeweils genau einer Version. Es können also Versionen unterschiedlicher Verzeichnisse und Dateien aus mehreren Zeitpunkten enthalten sein. Damit wäre eine Anzeige in der Versionshistorie nicht konsistent.

Um dieses Prinzip deutlicher zu machen, werden wir uns zunächst dem Anlegen von Labels widmen. Ausgangssituation ist folgender Aufbau der Versionsverwaltung:

Die rot markierten Verzeichnisse sollen “gelabelt” werden und zwar mit dem Label “Stable”. Mit einem Rechtsklick auf das Verzeichnis (zunächst $/Calculator.Build/Development/Calculator) im Source Control Explorer erhält man die Möglichkeit, ein Label zu vergeben:

Nach Auswahl der Version, wird der gewünschte Name für das Label (hier: “Stable”) abgefragt. Es besteht auch die Möglichkeit, einen Kommentar für das Label einzutragen:

Man beachte den Titel des Dialog “Apply Label for Calculator”. In diesem Fall werden auf Verzeichnisebene alle Dateien und Unterverzeichnisse (rekursiv) gelabelt. Ein Label besitzt zusätzlich einen Owner (engl. für Besitzer). Das ist der Benutzer, der das Label initial anlegt – hier der Benutzer “Peter”. Zudem hat ein Label auch einen Scope (engl. für Gültigkeitsbereich). Per Default ist der Gültigkeitsbereich gleich dem Team-Projekt in dem das Label gesetzt wird. Benutzer “Peter” legt desweiteren ein Label “Stable” für Verzeichnis $/Calculator.Demo/Development/Calculator an. Um den Gültigkeitsbereich zu erläutern, werden nun 2 Szenarien dargestellt.

Im ersten Szenario legt dieser Benutzer ein Label gleichen Namens (“Stable”) in einem anderen Team-Projekt – Calculator.Prepare für das Verzeichnis /Development/Calculator an. Die Berechtigung “Label” vorausgesetzt ist das auch kein Problem und wird wie oben dargestellt im Visual Studio angelegt.

Im zweiten Szenario legt ein weiterer Benutzer “Dave” im gleichen Team-Projekt – Calculator.Demo – ein Label gleichen Namens (“Stable”) für ein anderes Verzeichnis – /Releases/Version 1.0 – an. Fehlt dem Benutzer die Berechtigung “Administer Label”, wird das Anlegen eines Labels “Stable” zunächst mit einer Fehlermeldung quittiert:

Das liegt daran, dass im Gültigkeitsbereich des vermeintlich neuen Labels bereits eines mit gleichem Namen existiert. Dieses wurde ja bereits von Peter angelegt. Damit wird das Anlegen des Labels zum Merge mit einem existierenden Label eines anderen Besitzers. Für diese Operation ist die Berechtigung “Administer Label” notwendig – allerdings eben nur für das Bearbeiten eines Labels eines anderen Besitzers:

Ist die Berechtigung gesetzt, klappt auch der Merge für das Label “Stable” im Calculator.Demo Projekt.

Im Anschluss stellen sich die Labels wie folgt dar (im Visual Studio über das Menü File -> Source Control -> Label -> Find Label):

Es gibt nun also 3 Labels mit Namen “Stable”, nach diesen 4 Label Operationen. Im zweiten Szenario wurde also lediglich gemergt, was kein neues, viertes Label zur Folge hat. Lediglich das Label im Team-Projekt Calculator.Prepare hat Benutzer Dave als Besitzer.

Ein Blick in die Datenbank des TFS zeigt deutlich die Bedeutung des Gültigkeitsbereichs (Tabelle: tbl_Label):

Die Spalte ItemId definiert den Gültigkeitsbereich in Form eines versionierten Elements (Verzeichnisses). Ein Blick in die Tabelle tbl_Namespace zeigt die Elementnamen hinter den ItemIds:

Dies zeigt, dass bei mit dem Visual Studio erzeugten Labels, automatisch der Team-Projektknoten der Versionskontrolle als Gültigkeitsbereich gesetzt wird. Der Gültigkeitsbereich lässt sich via Kommandozeile auch umsetzen, indem an den Labelnamen “@Scope“angehängt wird, wobei Scope ein Verzeichnis in der Versionskontrolle bezeichnet (“tf.exe label /server:tfs “[email protected]$/Calculator.Prepare/Development/Calculator” “$/Calculator.Prepare/Development/Calculator” /recursive”). Legt man ein Label mit gleichem Namen oberhalb des Gültigkeitsbereiches an, welches diesen also beinhalten würde, erhält man folgende Meldung:

Das heißt, dass das alte Label im neuen aufgeht und danach nicht mehr existiert. Man hat dabei, wie im Dialog zu sehen, noch die Auswahl, ob die Versionen aus dem alten Label übernommen (Yes) oder verworfen werden sollen (No).

Noch ein Wort zum Versetzen von Labels. Angenomme, man hat ein Label “Stable” und möchte dieses “verschieben” nachdem ein Bug-fix gemacht worden ist. Wird beim Bug-fix z.B. eine Datei gelöscht, bleibt diese bei der erneuten Label-Operation im Label enthalten – und zwar in der alten Version:

Das bedeutet für eine spätere “Get Specific Version”-Operation auf Basis des Labels, dass die gelöschte Datei unter Umständen wieder auftaucht:

Hier deutet No in der Spalte Latest darauf hin, dass diese Datei nicht mehr in der aktuellen Version vorliegt. Allerdings nur, weil die übrigen Dateien im Label in der neuesten Version enthalten sind. Setzt man auf eine frühere Versionen zurück, kann das zum Konfigurationsdisaster werden. Es ist also empfehlenswert, beim Umsetzen von Labels dieses vorher zu löschen und damit neu anzulegen. Wobei darauf zu achten ist, dass der Labelname nicht für ein anderes Verzeichnis im gleichen Gültigkeitsbereich gesetzt ist. Dieses wird dann nämlich mit gelöscht!

Eine weitere Eigenschaft von Labels ist, dass es keine Historie darüber gibt. Nach dem Löschen oder Bearbeiten eines Labels ist kein Zurücksetzen möglich. Das könnte also problematisch für ein Audit sein. Hier müssen andere Wege (z.B. individuelle Datenbankbackups) gefunden werden.

Fazit

Mit dem korrekten Hintergrundwissen, kann mandie Mächtigkeit der TFS-Labels auch effektiv im Entwicklungsalltag einsetzen. Damit lassen sich unerwünschte Seiteneffekte (z.B. verlorengegangene Labels) vermeiden. Übrigens, die Revision eines Verzeichnisses lässt sich via Changeset-ID eindeutig konsistent herstellen. Es werden alle Versionsstände aller Verzeichnisse und Dateien wiederhergestellt, wie sie zum Zeitpunkt nach dem Einchecken des angegebenen Changesets vorgelegen haben.