9.2 Git und andere Systeme - Migration zu Git

Wenn Sie den vorherigen Abschnitt über die Verwendung von git svn gelesen haben, können Sie diese Anweisungen problemlos verwenden, um ein Repository mit git svn clone zu klonen. Beenden Sie dann die Verwendung des Subversion-Servers, pushen Sie zu einem neuen Git-Server und beginnen Sie mit diesem. Wenn Sie den Verlauf haben möchten, können Sie dies so schnell erledigen, wie Sie die Daten aus dem Subversion-Server abrufen können (was eine Weile dauern kann).

Der Import ist jedoch nicht perfekt; und da er so lange dauern wird, können Sie es auch gleich richtig machen. Das erste Problem sind die Autoreninformationen. In Subversion hat jede Person, die committet, einen Benutzer im System, der in den Commit-Informationen aufgezeichnet wird. Die Beispiele im vorherigen Abschnitt zeigen schacon an einigen Stellen, z. B. in der blame-Ausgabe und im git svn log. Wenn Sie dies zu besseren Git-Autoren-Daten zuordnen möchten, benötigen Sie eine Zuordnung von den Subversion-Benutzern zu den Git-Autoren. Erstellen Sie eine Datei namens users.txt, die diese Zuordnung in einem Format wie diesem enthält.

Um eine Liste der von SVN verwendeten Autorennamen zu erhalten, können Sie dies ausführen

Dadurch wird die Protokollausgabe im XML-Format generiert, dann werden nur die Zeilen mit Autoreninformationen beibehalten, Duplikate verworfen und die XML-Tags entfernt. Offensichtlich funktioniert dies nur auf einem Computer mit grep, sort und perl. Leiten Sie dann diese Ausgabe in Ihre Datei users.txt um, damit Sie die entsprechenden Git-Benutzerdaten neben jedem Eintrag hinzufügen können.

Sie können diese Datei an git svn übergeben, um die Autorenzuordnung genauer zu gestalten. Sie können git svn auch anweisen, die Metadaten, die Subversion normalerweise importiert, nicht einzuschließen, indem Sie --no-metadata an den Befehl clone oder init übergeben. Die Metadaten enthalten eine git-svn-id in jeder Commit-Nachricht, die Git während des Imports generiert. Dies kann Ihren Git-Verlauf aufblähen und ihn etwas unklar machen.

Dadurch sieht Ihr import-Befehl wie folgt aus:

Jetzt sollten Sie einen schöneren Subversion-Import im Verzeichnis my_project haben. Anstatt Commits, die so aussehen:

sehen sie so aus:

Nicht nur das Feld Autor sieht viel besser aus, sondern auch die git-svn-id ist nicht mehr vorhanden.

Sie sollten auch eine kleine Bereinigung nach dem Import durchführen. Zum einen sollten Sie die seltsamen Referenzen bereinigen, die git svn eingerichtet hat. Zuerst verschieben Sie die Tags, damit sie tatsächliche Tags und keine seltsamen Remote-Branches sind, und dann verschieben Sie die restlichen Branches, damit sie lokal sind.

Um die Tags zu echten Git-Tags zu verschieben, führen Sie Folgendes aus:

Dies nimmt die Referenzen, die Remote-Branches waren und mit refs/remotes/tags/ begannen, und macht sie zu echten (leichtgewichtigen) Tags.

Verschieben Sie als Nächstes die restlichen Referenzen unter refs/remotes in lokale Branches:

Es kann vorkommen, dass Sie einige zusätzliche Branches sehen, die mit @xxx (wobei xxx eine Zahl ist) enden, obwohl in Subversion nur ein Branch sichtbar ist. Dies ist tatsächlich eine Funktion von Subversion, die als "Peg-Revisions" bezeichnet wird und für Git keine syntaktische Entsprechung hat. Daher fügt git svn einfach die SVN-Versionsnummer zum Branch-Namen hinzu, so wie Sie sie in SVN geschrieben hätten, um die Peg-Revision dieses Branches zu adressieren. Wenn Ihnen die Peg-Revisions egal sind, entfernen Sie sie einfach:

Jetzt sind alle alten Branches echte Git-Branches und alle alten Tags echte Git-Tags.

Es gibt noch eine letzte Sache zu bereinigen. Leider erstellt git svn einen zusätzlichen Branch namens trunk, der dem Standard-Branch von Subversion entspricht, aber der trunk-Ref zeigt auf dieselbe Stelle wie master. Da master idiomatischer für Git ist, entfernen Sie den zusätzlichen Branch wie folgt:

Das Letzte, was zu tun ist, ist, Ihren neuen Git-Server als Remote hinzuzufügen und dorthin zu pushen. Hier ist ein Beispiel, wie Sie Ihren Server als Remote hinzufügen:

Da Sie möchten, dass alle Ihre Branches und Tags hochgeladen werden, können Sie jetzt Folgendes ausführen:

Alle Ihre Branches und Tags sollten auf Ihrem neuen Git-Server in einem schönen, sauberen Import sein.

Da Mercurial und Git ziemlich ähnliche Modelle zur Darstellung von Versionen haben und Git etwas flexibler ist, ist die Konvertierung eines Repositorys von Mercurial zu Git recht einfach. Dabei wird ein Tool namens "hg-fast-export" verwendet, von dem Sie eine Kopie benötigen:

Der erste Schritt bei der Konvertierung ist, einen vollständigen Klon des Mercurial-Repositorys zu erhalten, das Sie konvertieren möchten:

Der nächste Schritt ist die Erstellung einer Autorenzuordnungsdatei. Mercurial ist beim Inhalt des Autorenfelds für Changesets etwas nachsichtiger als Git, daher ist dies ein guter Zeitpunkt, um aufzuräumen. Das Generieren hiervon ist ein Einzeiler-Befehl in einer bash-Shell:

Dies dauert ein paar Sekunden, abhängig von der Länge der Projekthistorie. Danach wird die Datei /tmp/authors ungefähr so aussehen:

In diesem Beispiel hat dieselbe Person (Bob) Changesets unter vier verschiedenen Namen erstellt, von denen einer eigentlich korrekt aussieht und einer für einen Git-Commit völlig ungültig wäre. Hg-fast-export ermöglicht es uns, dies zu beheben, indem wir jede Zeile in eine Regel umwandeln: "<input>"="<output>", die einen <input> einem <output> zuordnet. Innerhalb der Zeichenfolgen <input> und <output> werden alle Escape-Sequenzen unterstützt, die von der Python-Codierung string_escape verstanden werden. Wenn die Autorenzuordnungsdatei keine übereinstimmende <input> enthält, wird dieser Autor unverändert an Git weitergeleitet. Wenn alle Benutzernamen in Ordnung aussehen, benötigen wir diese Datei überhaupt nicht. In diesem Beispiel soll unsere Datei so aussehen:

Eine ähnliche Zuordnungsdatei kann verwendet werden, um Branches und Tags umzubenennen, wenn der Mercurial-Name von Git nicht erlaubt ist.

Der nächste Schritt ist die Erstellung unseres neuen Git-Repositorys und die Ausführung des Export-Skripts:

Das Flag -r gibt hg-fast-export an, wo das Mercurial-Repository gefunden werden kann, das wir konvertieren möchten, und das Flag -A teilt ihm mit, wo die Autorenzuordnungsdatei gefunden werden kann (Branch- und Tag-Zuordnungsdateien werden durch die Flags -B bzw. -T angegeben). Das Skript analysiert Mercurial-Changesets und konvertiert sie in ein Skript für die "fast-import"-Funktion von Git (die wir später ausführlich besprechen werden). Dies dauert eine Weile (obwohl es *wesentlich* schneller ist als über das Netzwerk), und die Ausgabe ist recht ausführlich:

Das ist so ziemlich alles. Alle Mercurial-Tags wurden in Git-Tags konvertiert, und Mercurial-Branches und Bookmarks wurden in Git-Branches konvertiert. Jetzt sind Sie bereit, das Repository zu Ihrem neuen Server-Home zu pushen.

Das nächste System, das wir importieren werden, ist Perforce. Wie oben diskutiert, gibt es zwei Möglichkeiten, Git und Perforce miteinander reden zu lassen: git-p4 und Perforce Git Fusion.

Wenn Ihr System nicht eines der oben genannten ist, sollten Sie online nach einem Importeur suchen – für viele andere Systeme sind qualitativ hochwertige Importeure verfügbar, darunter CVS, Clear Case, Visual Source Safe, sogar ein Archivverzeichnis. Wenn keines dieser Werkzeuge für Sie funktioniert, Sie ein obskureres Werkzeug haben oder anderweitig einen benutzerdefinierteren Importprozess benötigen, sollten Sie git fast-import verwenden. Dieser Befehl liest einfache Anweisungen von stdin, um spezifische Git-Daten zu schreiben. Es ist viel einfacher, Git-Objekte auf diese Weise zu erstellen, als die rohen Git-Befehle auszuführen oder zu versuchen, die rohen Objekte zu schreiben (weitere Informationen finden Sie unter Git Internals). Auf diese Weise können Sie ein Importskript schreiben, das die erforderlichen Informationen aus dem zu importierenden System ausliest und einfache Anweisungen nach stdout ausgibt. Sie können dann dieses Programm ausführen und seine Ausgabe durch git fast-import leiten.

Um dies schnell zu demonstrieren, schreiben wir einen einfachen Importeur. Angenommen, Sie arbeiten in current, sichern Sie Ihr Projekt, indem Sie das Verzeichnis gelegentlich in ein zeitgestempeltes Sicherungsverzeichnis back_YYYY_MM_DD kopieren, und Sie möchten dies in Git importieren. Ihre Verzeichnisstruktur sieht so aus:

Um ein Git-Verzeichnis zu importieren, müssen Sie überprüfen, wie Git seine Daten speichert. Wie Sie sich vielleicht erinnern, ist Git im Grunde eine verkettete Liste von Commit-Objekten, die auf einen Schnappschuss des Inhalts verweisen. Alles, was Sie tun müssen, ist, fast-import mitzuteilen, was die Inhaltschnappschüsse sind, welche Commit-Daten darauf verweisen und in welcher Reihenfolge sie auftreten. Ihre Strategie wird sein, die Schnappschüsse nacheinander durchzugehen und Commits mit den Inhalten jedes Verzeichnisses zu erstellen und jeden Commit mit dem vorherigen zu verknüpfen.

Wie wir in Ein Beispiel für eine Git-erzwungene Richtlinie getan haben, schreiben wir dies in Ruby, da es das ist, womit wir im Allgemeinen arbeiten und es tendenziell leicht zu lesen ist. Sie können dieses Beispiel ziemlich einfach in jeder Sprache schreiben, mit der Sie vertraut sind – es muss nur die entsprechenden Informationen nach stdout ausgeben. Und wenn Sie unter Windows arbeiten, müssen Sie besonders darauf achten, keine Wagenrückläufe am Ende Ihrer Zeilen einzufügen – git fast-import ist sehr daran interessiert, nur Zeilenvorschübe (LF) zu erhalten und nicht die Wagenrücklauf-Zeilenvorschübe (CRLF), die Windows verwendet.

Zuerst wechseln Sie in das Zielverzeichnis und identifizieren jedes Unterverzeichnis, das jeweils ein Schnappschuss ist, den Sie als Commit importieren möchten. Sie wechseln in jedes Unterverzeichnis und geben die Befehle aus, die zum Exportieren erforderlich sind. Ihre grundlegende Hauptschleife sieht so aus:

Sie führen print_export innerhalb jedes Verzeichnisses aus, das das Manifest und die Markierung des vorherigen Schnappschusses übernimmt und das Manifest und die Markierung dieses Schnappschusses zurückgibt. Auf diese Weise können Sie sie ordnungsgemäß verknüpfen. "Mark" ist der fast-import-Begriff für einen Bezeichner, den Sie einem Commit geben. Während Sie Commits erstellen, geben Sie jedem einen Mark, den Sie verwenden können, um von anderen Commits darauf zu verweisen. Das Erste, was Sie in Ihrer Methode print_export tun, ist, eine Markierung aus dem Verzeichnisnamen zu generieren:

Dies tun wir, indem wir ein Array von Verzeichnissen erstellen und den Indexwert als Markierung verwenden, da eine Markierung eine Ganzzahl sein muss. Ihre Methode sieht so aus:

Nachdem Sie eine ganzzahlige Darstellung Ihres Commits haben, benötigen Sie ein Datum für die Commit-Metadaten. Da das Datum im Namen des Verzeichnisses angegeben ist, parsieren wir es. Die nächste Zeile in Ihrer Datei print_export ist:

wobei convert_dir_to_date wie folgt definiert ist:

Dies gibt einen ganzzahligen Wert für das Datum jedes Verzeichnisses zurück. Das letzte Stück Metainformation, das wir für jeden Commit benötigen, sind die Committer-Daten, die wir in einer globalen Variablen hartcodieren:

Jetzt sind Sie bereit, mit der Ausgabe der Commit-Daten für Ihren Importeur zu beginnen. Die anfänglichen Informationen besagen, dass Sie ein Commit-Objekt definieren und auf welchem Branch es sich befindet, gefolgt von der generierten Markierung, den Committer-Informationen und der Commit-Nachricht sowie dem vorherigen Commit, falls vorhanden. Der Code sieht so aus:

Wir hartcodieren die Zeitzone (-0700), da dies einfach ist. Wenn Sie aus einem anderen System importieren, müssen Sie die Zeitzone als Offset angeben. Die Commit-Nachricht muss in einem speziellen Format angegeben werden:

Das Format besteht aus dem Wort data, der Größe der zu lesenden Daten, einem Zeilenumbruch und schließlich den Daten. Da wir dasselbe Format verwenden müssen, um später die Dateiinhalte anzugeben, erstellen wir eine Hilfsmethode, export_data:

Alles, was noch zu tun ist, ist die Angabe der Dateiinhalte für jeden Schnappschuss. Das ist einfach, da wir jeden in einem Verzeichnis haben – Sie können den Befehl deleteall gefolgt vom Inhalt jeder Datei im Verzeichnis ausgeben. Git speichert dann jeden Schnappschuss entsprechend:

Hinweis: Da viele Systeme ihre Revisionen als Änderungen von einem Commit zum nächsten betrachten, kann fast-import auch Befehle mit jedem Commit entgegennehmen, um anzugeben, welche Dateien hinzugefügt, entfernt oder geändert wurden und wie die neuen Inhalte aussehen. Sie könnten die Unterschiede zwischen Schnappschüssen berechnen und nur diese Daten angeben, aber das ist komplexer – Sie können Git auch alle Daten geben und es die Arbeit machen lassen. Wenn dies besser zu Ihren Daten passt, lesen Sie die fast-import-Manpage für Details, wie Sie Ihre Daten auf diese Weise bereitstellen.

Das Format zum Auflisten der neuen Dateiinhalte oder zum Angeben einer geänderten Datei mit den neuen Inhalten lautet wie folgt:

Hier ist 644 der Modus (wenn Sie ausführbare Dateien haben, müssen Sie 755 erkennen und angeben), und inline bedeutet, dass Sie die Inhalte direkt nach dieser Zeile auflisten werden. Ihre Methode inline_data sieht so aus:

Sie verwenden die zuvor definierte Methode export_data wieder, da sie die gleiche ist, wie Sie Ihre Commit-Nachrichtendaten angegeben haben.

Das Letzte, was Sie tun müssen, ist die Rückgabe der aktuellen Markierung, damit sie an die nächste Iteration übergeben werden kann:

Das ist alles. Hier ist das Skript in seiner Gesamtheit:

Wenn Sie dieses Skript ausführen, erhalten Sie eine Ausgabe, die ungefähr so aussieht:

Um den Importeur auszuführen, leiten Sie diese Ausgabe über git fast-import, während Sie sich im Git-Verzeichnis befinden, in das Sie importieren möchten. Sie können ein neues Verzeichnis erstellen und dann git init darin ausführen, um einen Ausgangspunkt zu haben, und dann Ihr Skript ausführen:

Wie Sie sehen können, gibt es bei erfolgreicher Ausführung eine Menge Statistiken darüber aus, was erreicht wurde. In diesem Fall haben Sie insgesamt 13 Objekte für 4 Commits in 1 Branch importiert. Jetzt können Sie git log ausführen, um Ihre neue Historie zu sehen:

Da haben Sie es – ein schönes, sauberes Git-Repository. Es ist wichtig zu beachten, dass nichts ausgecheckt ist – Sie haben zunächst keine Dateien in Ihrem Arbeitsverzeichnis. Um sie zu erhalten, müssen Sie Ihren Branch zurücksetzen, wo master jetzt ist:

Sie können mit dem fast-import-Tool noch viel mehr tun – verschiedene Modi, Binärdaten, mehrere Branches und Merges, Tags, Fortschrittsanzeigen und mehr. Eine Reihe von Beispielen für komplexere Szenarien finden Sie im Verzeichnis contrib/fast-import des Git-Quellcodes.