2009-07-20 9 views
6

Diese Frage ähnelt this one und this one, aber das Szenario ist etwas komplexer.Wie verhält sich git-svn mit Svn-Repositorys, die das Layout geändert haben?

Ich begann vor ein paar Jahren mit einem privaten Svn-Repository (die ich hauptsächlich für gemeinsame Konfigurationsdateien und dergleichen zwischen verschiedenen Maschinen verwendet). Ich war nicht so vorsichtig mit dem Layout des Repository (wo Zweige, gehen, etc.), so hat es sich im Laufe der Zeit ziemlich verändert. Das war natürlich ein Fehler, aber jetzt ist es zu spät. Vor kurzem habe ich es zu einem Standard-SVN-Stamm/Zweigen/Tags-Layout migriert, hauptsächlich mit svn move-Befehlen, aber natürlich ist die alte Geschichte noch im Repository vorhanden (und ehrlich gesagt, ein bisschen Chaos) .

Ich möchte jetzt dies dauerhaft in ein Git-Repository konvertieren. Ich habe versucht, git-svn zu verwenden, aber es scheint nur Situationen zu behandeln, in denen eine konsistente trunk/branch/tag-Konvention gefolgt wurde (ja, Sie können alternative Namen angeben, aber nur eine für jeden, es erscheint). Ein Großteil der Historie meines Repositorys hat einen Stamm im Stammverzeichnis des Repositorys, zum Beispiel mit Tags/und Zweigen/als Unterverzeichnissen.

Was ist der beste Weg, all dies zu behandeln? Idealerweise hätte ich gerne das git-Repository, das ich am Ende habe, um zumindest die gesamte Geschichte irgendwie zugänglich zu machen, selbst wenn die Zweige und Tags nicht richtig als erstklassige Konzepte in git dargestellt werden.

Genauer gesagt, wie wird Svn-Git Dateien außerhalb der Stamm/Zweige/Tags Unterverzeichnisse behandeln, mit denen es versehen ist? Meine bisherigen Beobachtungen sind, dass es sie manchmal vermisst (definitiv nicht OK), und andere Male sie zu dem neuen Repository hinzufügt.

Alle Gedanken würden geschätzt werden.

+0

Sie fragen, wie es sich verhalten werde aber auch sagen, Sie haben es probiert. Spezifische Beispiele für unerwünschtes Verhalten, die Sie beobachtet haben, wären hilfreich. Git ist normalerweise erstaunlich gut im Umgang mit komplexen Zusammenführungen, z. B. Ändern und Verschieben eines Teilbaums in demselben Commit. –

+0

OK - Ich habe es versucht. Ich gebe zu, dass ich mich vielleicht nicht vollständig mit den Ergebnissen befasst habe, aber meine oberflächlichen Beobachtungen waren sicherlich, dass git-svn einige Verzeichnisse aus der svn-Wurzel (d. H. Außerhalb der Stamm-/Zweig-/Tag-Verzeichnisse) enthielt, aber keine anderen. Ich war verwirrt darüber, warum. git sicher ist in der Lage, komplexe Zusammenführungen zu behandeln, aber ich denke, diese Frage ist mehr über Git-Svn als Git selbst. –

+0

Verwenden Sie ['svn'] -Tag anstelle von [' subversion'] -Tag http://meta.stackexchange.com/questions/2601/batch-retag-request-merge-svn-and-subversion –

Antwort

2

Meiner Erfahrung nach besteht die einzige Möglichkeit darin, den Speicherort des Repositorys im Laufe der Zeit zu verfolgen und einen separaten git-svn-Klon für jede Periode zu erstellen, in der das Projekt an einem Ort verbleibt.

Nachdem Sie die Repositorys für verschiedene Phasen in der Zeit erstellt haben (oder zumindest so weit zurück, wie Sie sich kümmern können), können Sie die Repositorys zusammenfügen.

Ich habe ein Screen erstellt diese Technik demonstriert hier:

http://blog.tfnico.com/2010/10/gitsvn-6-grafting-together-svn-history.html

Verwandte Themen