Von SourceSafe nach Vault


Thomas Wölfer
Thomas Wölfer

10. April 2008


Als Revision Control System haben wir in den letzten Jahren Source Safe eingesetzt. Nun ist mir bewusst, das Source Safe keinen besonders guten Ruf hat - ich kann aber wirklich nicht sagen, das wir damit irgend ein Problem gehabt hätten. (Bei der Umstellung tauchte dann zum ersten mal eines auf - aber zuvor hat die Sache für uns eigentlich recht gut funktioniert.)

Das Setup sah dabei bisher so aus, das die Oberhausener und die Münchner Niederlassung per VPN verbunden waren: Dazwischen gab es (unter anderem) eine 2MBit Standleitung, durch die die Oberhausener "durch" mussten, denn die Daten selbst waren auf einem Server in München. Das sollte anders werden, damit auch bessere Geschwindkeiten als 2MBit erzielt werden können. Ziel: Das RCS sollte auf einen Server im Internet, der mindestens mit 100 MBit erreichbar ist.

Da fing das Problem an: Bei Source Safe gibt es zwar die Möglichkeit auf die Daten per HTTP zuzugreifen - allerdings nur in sehr eingeschränktem Umfang: So kann man per HTTP beispielsweise keine Dateien löschen. Es musste also ein anderes RCS her. Ich habe mir verschiedene angesehen (und ja: Ich weiss auch das es Subversion gibt) und mich letztlich für Vault von SourceGear entschieden.

Ein RCS-Wechsel ist eine heikle Sache: Da drin befindet sich schließlich die Arbeit der letzten Jahre und zwar mit allen Änderungen: Diese Daten will man nicht verlieren. Um eines vorweg zu nehmen: Das hat mit Vault auch im großen und ganzen geklappt.

Der Wechsel zu Vault

Um den Wechsel durchführen zu können, müssen die Daten in Source Safe zunächst einmal so sauber wie möglich vorliegen: Das heist, man wirft zunächst das Analyse Tool von Source Safe an, und behandelt alle auftretenden Probleme. Im meinem Fall hat das Tool in den letzten Jahren noch nie einen Fehler gefunden, und so hatte ich auch nicht gerade jetzt damit gerechnet. Es gab aber einen, und der wurde auch nicht vom durch analyze vorgeschlagenen Vorgehen beseitigt: Eine Datei wollte einfach nicht mehr repariert werden können. Folgende Fehlermeldung trat auf:

There is a diff chain size mismatch in file 'overview.xml' (tugbaaaa) at version 7 (versions earlier than that version can no longer be retrieved from the database).

Sollte sonst mal wer über dieses Problem stolpern: Man kann es mit dem ssarc Tool beseitigen. Dieser KB-Artikel erklärt wie das geht.

Danach fand ich aber noch ein anderes Problem: Es gab Dateien die ausgecheckt waren - die aber schon seit Jahren nicht mehr Teil des Projektes waren. Es gab sie also eigentlich nicht mehr, Source Safe dachte aber, sie seien nur ausgecheckt. Ärgerlich. (Das wird in Zukunft nicht mehr passieren, da unser neuer automatischer Build-Server sowas finden und "bemängeln" wird.)

So ein Problem kann man aber auch mit einem Kommandozeilen-Tool von SourceSafe beseitigen: Man führt für die betroffenen Dateien ein Undo-Checkout unter dem SS-Account desjenigen aus, von dem SourceSafe glaubt, er oder sie hätte die Datei ausgecheckt.

Die Installation von Vault ist an sich kein besonderes Problem: Alles was man vorher braucht ist ein SQL Server (die Express-Variante tut es auch) und ein laufender IIS mit ASP.Net.

Dann kommt der spannende Teil: Das Importieren der Daten. Von SourceGear gibt es dazu ein VSSImport-Tool. Das muss auf dem Rechner installiert werden, der zuvor der SS Server war. Dann zeigt man dem Tool den Pfad auf die ss.ini und gibt noch an, wo der neue Vault Server installiert wurde.

Das Import-Tool durchläuft dann zwei Phasen: Eine "Pre-Scan" Phase sowie die eigentliche Konvertierung. Die Pre-Scan Phase ist relativ schnell durchlaufen - und wenn sie das ist, gibt es eine erste Angabe, wie lange denn der Import dauern würde: In Fall unseres "größten" Projektes (mit etwa 10.000 Files) schätzte das Import-Werkzeug den Zeitaufwand auf 22 Stunden. So lange hats dann nicht gedauert - aber 12 Stunden waren es locker. Wer nicht nur alle Änderungen sondern auch "Labels" importieren will muss sich in Geduld üben: Bei einem Projekt dessen Import nur ca. 10 Minuten gedauert hat, habe ich den "Label-Import" mal ausprobiert, aber nach etwa 5 Stunden abgebrochen. Beim großen Projekt habe ich es dann gar nicht erst versucht.

Ist die Sache importiert zeigt das Tool (möglicherweise: bei mir in einem von 3 Fällen) eine Liste an Fehlermeldungen an: Unter Umständen konnten einige Dateien nicht hochgeladen werden, oder es gab vielleicht andere Probleme: Die untersucht man besser von Hand und beseitigt sie. Danach hat man eine "funktionierende" Datenbank - man kann also ein "Get Latest" in ein frisches Verzeichnis machen, und ein Build starten.

Abgesehen von ein paar Dingen die ich für Anfangs/Umstiegsschwierigkeiten halte bin ich von Vault bisher rundrum begeistert: Ein "GetLatest" ist dramatisch viel schneller als bei SourceSafe und die Daten liegen obendrein im SQL Server vor - das macht auch das sichern deutlich einfacher.

Wer es selbst mal ausprobieren will: Die Single-User Version von Vault ist kostenlos.