Wir haben die meisten unserer Codebasen von einem monolithischen svn -Repository in eine Reihe von git -Repositorys verschoben. Aus verschiedenen Gründen müssen einige Arbeiten (an alten Versionen des im Feld eingesetzten Projekts) in den alten svn -Zweigen fortgesetzt werden, nachdem sie in git verschoben und aus der Subversion trunk gelöscht wurden.
Ich habe so etwas in einem svn Zweig gemacht und die Änderungen aus dem svn Repository in die git Repositories übernommen, indem ich Folgendes gemacht habe:
aber es ist ziemlich umständlich, dies für jedes svn commit zu tun, besonders für den gedit Schritt, wo ich die svn Pfade manuell in git Pfade migrieren muss (normalerweise indem ich die oberste Ebene voranstelle) Verzeichnisname).
Ein Problem beim Ausprobieren einiger der bisher vorgestellten Optionen ist, dass die Struktur des alten svn Repos und des neuen git Repos unterschiedlich ist. Dies ist einer der Gründe, warum ich die Patch-Datei bearbeiten muss.
Die alte Verzeichnisstruktur war
%Vor%Während die neue Struktur
ist %Vor%Ich würde wirklich gerne wissen, ob es einen einfacheren Weg gibt, dies zu tun und zu verstehen, was die beste Vorgehensweise für diese Situation ist.
Wenn Sie davon ausgehen, dass die Verzeichnisstruktur Ihrer Quellen gleich bleibt, schlage ich vor, dass Sie Ihrem alten SVN-Zweig eine Fernbedienung hinzufügen:
%Vor%Auf diese Weise können Sie Änderungen in alten SVN-Zweigen und Ihrem brandneuen Git-Server in lokalen Niederlassungen verfolgen und git-cherry-pick , um die Commits mit den Fixes auf den Git-Server-Zweigen anzuwenden.
BEARBEITEN
Git verfolgt die Dateibewegungen.
Ich habe es selbst nicht versucht, aber wenn Sie den SVN-Repo klonen, dann verschieben Sie die Verzeichnisse lokal, um sie an Ihre neue Git-Server-Struktur anzupassen. Cherry-Pick-Merges könnten sie auf die verschobenen Dateien anwenden.
Für einige Dateien funktionierte es bereits, aber vielleicht gibt es ein paar Einschränkungen. Es ist definitiv einen Versuch wert.
Sie können git svn verwenden, um Ihren Git Repo mit den Änderungen von svn zu synchronisieren.
%Vor%Das wird Sie mit den Svn-Quellen in einem Git-Zweig verlassen. Um von Svn zu Git zu synchronisieren:
%Vor%Wir haben bessere Erfahrungen mit Rebase als mit Merge. Hoffentlich erledigt das auch die Arbeit für Sie.
Nichts verbietet es, dass git und svn in der Quellstruktur koexistieren. Dies macht das Auswählen von Commits viel einfacher als das Patchen und Kopieren zwischen verschiedenen Quellbäumen.
svn checkout ein Zweig und eine Revision, die Sie bereits in git haben. git clone und git checkout der gleiche Quellbaum wie in Schritt 1 (es könnte eine Abkürzung geben, die leere Repositories einbezieht, wenn das Repository sehr groß ist - Sie benötigen nur die .git/ Repository-Daten). .git/ -Verzeichnis in Ihr svn-Checkout-Stammverzeichnis. git , um Subversion-Metadaten zu ignorieren, indem Sie .svn in Ihre .gitignore -Datei einfügen. svn propset svn:ignore dirname .git auch ausführen, um svn ignore .git director zu sagen. Jetzt gibt es viele Methoden, um die Commits zu exportieren. Hier ist eine Methode, wenn Sie commit r12345 übernehmen wollen (unter der Annahme, dass ein Punkt wie oben ist, wo svn und git beide aktuell sind):
git checkout -b throway-branch ); svn co -r12344 ; git -Repository, indem Sie etwas wie git add -A gefolgt von git commit -m "SVN -r12344 (uninteresting stuff)" ; svn co -r12345 und git add -A && git commit --date <svn commit date>
(Verwenden Sie hier --date <svn commit date> unter der Annahme, dass Sie das SVN-Commit-Datum beibehalten möchten). git cherry-pick diese letzte bedeutungsvolle Verpflichtung zu Ihrem tatsächlichen Zweig, den Sie in der Welt veröffentlichen möchten. Diese Art von Dual-Repository-Setup funktionierte für mich ziemlich gut, als ich einmal mit dem Upstream-Subversion-Repository arbeiten musste, während ich git lokal verwendete. Ich habe am Ende ein paar Skripte gemacht, um das alles einfacher zu machen. Z.B. Für Sie könnte ein Skript das svn-Commit-Datum und die Nachricht aufnehmen und ein git-commit für Sie mit demselben Datum und derselben Nachricht erstellen (mit der svn-Revisionsnummer, die der Nachricht hinzugefügt wurde, um sie mit dem svn-Commit abzugleichen).
Alternativ können Sie auch svn diff --git und git am verwenden, wie Sie in Ihrem Post erwähnen, was viel praktischer ist, da Sie die Patches nicht zwischen verschiedenen Verzeichnissen verschieben müssen und Sie können Ihr einzelnes Arbeitsverzeichnis immer mit Ihrem vergleichen svn checkout und aktuelle git commit jederzeit.
Ich bin nicht vertraut mit git svn zu wissen, ob dies ein nützliches Werkzeug für Sie wäre.