Beim Import des Multiprojekt-SVN-Repositorys werden nicht alle mit svn copy erstellten Dateien importiert

Question

Wir versuchen, ein Legacy-SVN-Repository mit mehreren Projekten in mehrere Git-Repositories zu verschieben.

Unser Repository-Setup ist ähnlich wie folgt: https://daneomatic.com/2010/11/01/svn-to-multiple-git-repos/, und nach den Vorschlägen in diesem Post - obwohl veraltet - führt zu ordnungsgemäß aufgeteilt Repositories.

Der eigentliche Vorgang der Aufteilung der Projekte in verschiedene Repositorys ist in Ordnung, aber nach dem Import des svn-Repository in git waren mehrere Dateien und Ordner nach dem Import nicht vorhanden.

Ich verfolgt es auf Dateien und Ordner nach unten, wo die svn log zeigten, dass sie von anderen Orten in der SVN-Baum kopiert worden SVN war, und egal, welche Fahnen mit ich experimentieren, wenn git svn clone (wie die Angabe trunk ausgeführt wird, unter Verwendung von filter-branch und ähnlich) es scheint wie git-svn ist nicht in der Lage, die Svn CP zu lösen, was zu fehlenden Dateien und Ordnern nach dem Import abgeschlossen hat.

Meine Theorie ist, dass der Git Svn-Import die SVN-Kopie nicht "auflösen" kann. Selbst bei einem vollständigen Import des gesamten Repositorys fehlen die fraglichen Dateien und im Vergleich zu einem normalen svn-Checkout kann ich mehrere fehlende Dateien und Ordner lokalisieren.

Hat jemand irgendwelche Erfahrung mit diesem, Flaggen, die ich auf git svn verwenden kann, oder Werkzeugvorschläge, um einen Import so zu vervollständigen? Ich möchte den Import vervollständigen und die Geschichte einigermaßen intakt halten.

Answer 1

Für eine einmalige Migration git-svn ist nicht das richtige Tool für die Konvertierung von Repositories oder Teile von Repositories. Es ist ein großartiges Tool, wenn Sie Git als Frontend für einen vorhandenen SVN-Server verwenden möchten, aber für einmalige Conversions sollten Sie nicht verwenden, sondern svn2git, was für diesen Anwendungsfall wesentlich besser geeignet ist.

Es gibt viele Werkzeuge, die svn2git genannt werden, die wahrscheinlich beste ist die KDE eine von . Ich empfehle dringend, das Werkzeug svn2git zu verwenden. Es ist das Beste, was ich kenne, und es ist sehr flexibel in was man mit seinen Regeldateien machen kann.

Sie können einfach svn2git s Regeldatei konfigurieren, um das gewünschte Ergebnis aus Ihrem aktuellen SVN-Layout zu erzeugen, einschließlich eventuell existierender komplexer Historien einschließlich der Erstellung mehrerer Git-Repos aus einem SVN-Repo oder der Kombination verschiedener SVN Repos sauber in einem Git Repo sauber in einem Lauf, wenn Sie möchten.

Wenn Sie sich nicht zu 100% mit dem Verlauf Ihres Repositorys befassen, ist svneverever von http://blog.hartwork.org/?p=763 ein großartiges Werkzeug, um den Verlauf eines SVN-Repositorys bei der Migration auf Git zu untersuchen.

---

Obwohl git-svn ist einfacher, mit zu beginnen, hier sind einige weitere Gründe, warum die KDE mit svn2git statt git-svn überlegen ist, neben seiner Flexibilität:

• die Geschichte wieder aufgebaut ist viel besser und sauberer von svn2git (wenn die richtige verwendet wird), ist dies besonders der Fall für komplexere Historien mit Verzweigungen und Zusammenführungen und so weiter
• die Tags sind echte Tags und keine Verzweigungen in Git
• mit git-svn Die Tags enthalten ein extra leeres Commit, das sie auch nicht zu den Zweigen macht, so dass ein normaler fetch sie erst erhält, wenn Sie dem Befehl geben, da standardmäßig nur Tags abgerufen werden, die auf abgerufene Zweige verweisen. Mit der richtigen svn2git-Tags sind, wo sie hingehören
• , wenn Sie das Layout in SVN geändert haben, können Sie einfach diese Konfiguration mit svn2git, mit git-svn werden Sie Geschichte verlieren schließlich
• mit svn2git können Sie auch Split ein SVN-Repository in leicht mehrere Git-Repositories
• oder kombinieren mehrere SVN-Repositories im gleichen SVN Wurzel in einem Git-Repository leicht
• die Umwandlung eine Unmenge mal schneller mit der richtigen svn2git ist als bei git-svn

Sie sehen, es gibt viele Gründe, warum git-svn ist schlechter und die KDE svn2git ist überlegen. :-)