Beibehaltung der Svn Kopie Geschichte beim Konvertieren in Git

Question

Ich versuche, ein SVN Repo über mehrere Git Repos zu konvertieren. Bisher habe ich git svn clone svn_repo_project_path für jedes Projekt in SVN verwendet. Ich habe bemerkt, dass git nicht den SVN-Kopiervorgängen zu folgen scheint, so dass die resultierende Geschichte viel kürzer ist als erwartet. Angenommen, mein SVN Repo sah wie folgt aus:

Wurzel

• ein
• b
• c
• Eltern-proj
  • b
  • c

Projekte b und c wurden unter parent-proj als Teil einer Umstrukturierungsanstrengung mit dem Ziel, schließlich zu löschen sie aus ihren alten Standorten unter root vor kurzem kopiert. Wenn ich git svn clone http://svnhost/parent-proj mache, fehlt dem resultierenden Git-Repo der gesamte Verlauf, der vor dem Verschieben von /b und /c stammt.

Ist dies eine Einschränkung von git-svn oder gibt es eine Möglichkeit, diese Geschichte in meinem Repo zu sehen? Aus meiner begrenzten Forschung scheint es, dass die Verwendung der filter-branch Befehl wie beschrieben in Getting complete history of an SVN repo that's been renamed using git-svn funktionieren kann, obwohl in meinem Fall gibt es mehrere Eltern, die wahrscheinlich Dinge kompliziert. Könnte man zuerst den gesamten Repo klonen und dann neue Repos daraus ausgliedern (mit Filter-Branch?), Wäre das ein besserer Ansatz?

Answer 1

Sie erhalten keine Vorkopie-zu-Eltern-Projekthistorie für b oder c, wenn Sie git svn clone http://svnhost/parent-proj. git svn interpretiert den von Ihnen bereitgestellten Basispfad als den flachsten Punkt, an dem Sie die SVN-Commits aufnehmen möchten, wodurch Git für dasselbe committiert wird. Da die historischen Commits unter b und c außerhalb dieses Pfades liegen, werden sie von git svn nicht gespiegelt, so dass Sie diesen Verlauf nicht haben.

in der Dokumentation Werfen Sie einen Blick für die git svn init --no-minimize-url Option:

Wenn mehrere Verzeichnisse Verfolgung (mit --stdlayout, --branches oder --tags Optionen), git svn die verbinden versucht Root (oder höchste zulässige Ebene) des Subversion-Repositorys. Diese Standardeinstellung ermöglicht eine bessere Protokollierung des Verlaufs, wenn ganze Projekte innerhalb eines Repositorys verschoben werden, kann jedoch Probleme in Repositories verursachen, in denen Lesezugriffsbeschränkungen vorhanden sind. Wenn Sie --no-minimize-url übergeben, kann git svn URLs unverändert übernehmen, ohne eine Verbindung zu einem übergeordneten Verzeichnis herzustellen. Diese Option ist standardmäßig deaktiviert, wenn nur eine URL/Zweigstelle verfolgt wird (dies würde wenig nutzen).

Da Ihr clone Befehl nicht angibt, mehrere Zweige (vielleicht, weil Sie ein komplexes, Multi-Projekt oder Nicht-Standard-Layout), git svn nur Klont diesen Weg und nach unten Commits beteiligt ist. Shadow Creeper in Kommentaren verwendet die -s oder --stdlayout Option, die erklären kann, warum einige Geschichte für sie erhalten wurde.

Wenn es sich um eine einmalige Konvertierung (unidirektionale Migration von SVN nach Git) handelt, sollten Sie wahrscheinlich das gesamte Repository klonen, dann haben Sie gute Möglichkeiten, Dinge in Git so zu verschieben, wie Sie es möchten zu, einschließlich der Einrichtung von historischen Branchen und Tags. Wenn die Motivation, filter-branch zu betreiben, darin besteht, Speicherplatz im Repository zu speichern, stellen Sie sicher, dass dies Ihnen tatsächlich etwas spart und dass es sich lohnt, die Mühe zu machen. Git ist sehr effizient mit Speicher.

Ein letztes Wort der Vorsicht auf Erwartungen der Geschichte-Suche in der Git-Klon. Suchen Sie nach Verlauf in einer Datei mit git log -C --follow <file-path> und Git wird in der Regel einen guten Job beim Suchen und Bereitstellen eines Verlaufs mit Umbenennungen und Kopien durchführen. Erwarten Sie das nicht für Verzeichnisse, z. parent-proj/b. Git verfolgt Blobs (Dateien), Bäume (von Blobs), Commits und Eltern-Commits, aber behandelt Verzeichnisse oder Verzeichniskopien nicht auf die gleiche Weise wie SVN.