Den Wechsel von Subversion (SVN) zu einer Git-basierten verteilten Versionskontrolle kann ein Software-Entwicklungsteam in fünf einfache Schritte aufbrechen und so nahtlos und zielgerichtet strukturieren. Nach der Vorbereitung des lokalen Rechners des Migrationsleiters steht als nächste Etappe der Import der Inhalte des SVN-Repositorys in ein neues Git-Repository an.
Hierfür bietet sich das git-svn-Utility an, das mit den meisten Git-Distributionen ausgeliefert wird. Anschließend werden die Ergebnisse dann mit den Werkzeugen in der Datei svn-migration-scripts.jar bereinigt.
Achtung: Dieser Konvertierungsprozess kann bei größeren Repositories recht viel Zeit in Anspruch nehmen, selbst wenn von einem lokalen SVN-Repository geklont wird. Ein Vergleichswert: Die Konvertierung eines 400-MB-Repositorys mit 33.000 Commits in den Master benötigte rund zwölf Stunden.
Wenn es sich um Repositories von halbwegs überschaubarer Größe handelt, sollten die folgenden Schritte auf dem lokalen Rechner des Migrationsleiters stattfinden. Ist das SVN-Repository allerdings sehr groß, kann man git svn clone auch auf dem SVN-Server laufen lassen, um die Konvertierungszeit zu verringern.
Das SVN-Repository klonen
Das Kommando git svn clone transformiert den Trunk, die Branches und die Tags des SVN-Repositorys in ein neues Git-Repository. Je nach Struktur des SVN-Repositorys müssen die Befehle unterschiedlich konfiguriert werden.
Standard-SVN-Layouts
Wenn das SVN-Projekt das standardmäßige Verzeichnis-Layout /trunk, /branches und /tags verwendet, kann der Migrationsleiter die Option --stdlayout nutzen, statt die Struktur des Repositorys manuell zu spezifizieren. Dazu führt er im Verzeichnis ~/GitMigration das folgene Kommando aus:
git svn clone --stdlayout --authors-file=authors.txt
<svn-repo>/<project> <git-repo-name>
<svn-repo> ist die URI des SVN-Repositorys, die migriert werden soll, <project> ist der Name des zu importierenden Projekts und <git-repo-name> ist der Verzeichnisname des neuen Git-Repositorys.
Nicht-Standard-SVN-Layouts
Entspricht das SVN-Repository nicht dem Standard-Layout, müssen die Positionen von Trunk, Branches und Tags mithilfe der Kommandozeilenoptionen --trunk, --branches und --tags spezifiziert werden. Sind Branches zum Beispiel sowohl im Verzeichnis /branches als auch im Verzeichnis /bugfixes gespeichert, müsste der Befehl diese Form haben:
git svn clone --trunk=/trunk --branches=/branches
--branches=/bugfixes --tags=/tags --authors-file=authors.txt
<svn-repo>/<project> <git-repo-name>
Überprüfung des neuen Git-Repositorys
Nachdem git svn clone beendet ist, was wie gesagt etwas dauern kann, findet sich unter ~/GitMigration ein neues Verzeichnis namens <git-repo-name>. Dabei handelt es sich um das konvertierte Git-Repository. Es sollte möglich sein, in dieses Verzeichnis zu wechseln und hier im Projekt direkt mit den Git-Standardbefehlen zu arbeiten.
Branches und Tags sind – anders als vielleicht erwartet – nicht in das neue Git-Repository importiert worden. Somit liefert git branch keine der SVN-Branches, git tag keine SVN-Tags. Erst der Befehl git branch -r zeigt die Branches und Tags aus dem SVN-Repository an. Der Befehl git svn clone importiert SVN-Branches nämlich als Remote-Branches und Tags als Remote-Branches mit dem Präfix tags/.
Dieses Verhalten macht gewisse Two-Way-Synchronisierungsprozesse einfacher, kann aber Verwirrung stiften, wenn man versucht, eine eingleisige Git-Migration durchzuführen. Der nächste Schritt besteht also nun darin, diese Remote-Branches in lokale Branches und tatsächliche Git-Tags umzuwandeln.
Bereinigung des neuen Git-Repositorys
Das Skript clean-git, das in der svn-migration-scripts.jar enthalten ist, macht aus diesen SVN-Branches lokale Git-Branches und aus SVN-Tags richtige Git-Tags. Achtung: Diese Operation ist destruktiv; es ist anschließend nicht mehr möglich, Commits aus dem Git-Repository zurück in das SVN-Repository zu verschieben.
Beim hier beschriebenen Migrationsprozess ist das kein Problem, da er eine One-Way-Synchronisierung von SVN zu Git vorsieht. (Das Git-Repository steht auf "read only", bis die Migration vollständig abgeschlossen ist.) Sind während des Migrationsprozesses jedoch Commits zum Git- und zum SVN-Repository vorgesehen, sollten die folgenden Befehle nicht durchgeführt werden. Es handelt sich hierbei um ein Vorgehen für Fortgeschrittene, das für viele Projekte nicht empfehlenswert ist.
Der folgende Befehl in ~/GitMigration/<git-repo-name> zeigt, was aufgeräumt werden kann:
java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar clean-git
Er gibt alle Änderungen aus, die das Skript vorschlägt, aber tatsächlich führt es keine davon aus. Um diese Änderungen anzustoßen, ist die Option --force nötig:
java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar clean-git
--force
Nun sollten in der git branch-Ausgabe alle SVN-Branches sichtbar sein und in der git tag-Ausgabe alle SVN-Tags. Damit ist das SVN-Projekt erfolgreich in ein Git-Repository konvertiert worden.
Zusammenfassung
In diesem Stadium hat der Migrationsleiter mit git svn clone ein neues Git-Repository aus einem SVN-Repository erzeugt und dessen Struktur bereinigt. Im nächsten Schritt geht es darum, das neue Git-Repo mit allen neuen Commits zum SVN-Repository zu synchronisieren. Der demnächst folgende Artikel dieser Reihe beschreibt dieses Vorgehen.
Weiterführende Infos: Ihr Partner für Git und Stash
Kennen Sie Stash von Atlassian? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.
Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.
Branch-basierte Git-Workflows mit Stash adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
Interview: Die Vorteile von Git in der Software-Entwicklung und die Möglichkeiten von Stash
So funktioniert die Lizenzierung von Atlassian-Produkten
