Wir erwägen derzeit die Migration von svn zu git für alle Vorteile, die git bietet. Wir sind derzeit besorgt, Geschichte zu verlieren und das Problem zu untersuchen. Wir würden gerne wissen, ob jemand andere Probleme hatte, als sie von svn zu git migrierten.
Es sollte keine Probleme beim Konvertieren von svn zu git hinsichtlich des Verlusts der Historie geben. Das ist der Hauptzweck der Software zur Versionskontrolle, um den Verlauf zu verfolgen.
Die Regel Nummer eins ist natürlich: Sichern Sie immer Ihre Repositories, bevor Sie sie konvertieren, und führen Sie mehrere Testläufe durch, bis Sie sich in einer Produktionsumgebung sicher genug fühlen.
Ein wesentlicher Unterschied ist die Art und Weise, in der sich externe Elemente in Subversion im Vergleich zu Git-Submodulen verhalten. Siehe:
Erwarten Sie auch, dass Sie etwas Zeit damit verbringen, die Benutzer zu unterstützen. Git ist ein anderes Biest und einige gewöhnliche svn-Benutzer können feststellen, dass es ein wenig unintelligent zu verwenden ist.
Bearbeiten: Git hat die Unterstützung für das Importieren und Arbeiten mit Svn-Repositories integriert, indem Sie git-svn .
Die meisten Probleme treten auf, wenn in SVN nicht standardmäßige Verzweigungen oder Tags vorhanden sind. Dies ist der Fall, wenn jemand den trunk/ Ordner nicht in tags/ oder branches/ kopiert hat, sondern nur in Unterordner. Diese Ordner werden als "abgerissene" Revisionen ohne gemeinsamen Vorfahren mit Stamm angezeigt. Aber das Inhalts-Selbst ist korrekt.
Git-SVN importiert den gesamten Subversion-Verlauf (und einige zusätzliche Metadaten) in Git repo
%Vor%-s, wenn Sie "Standard" Repo-Layout in Subversion
habenaber einige Autoren empfehlen,
zu verwenden %Vor%Einige zusätzliche nützliche Informationen:
Ich konnte den svn-Verlauf mit dem Zweigverlauf zum git-Repository mit dem Skript, das ich hier geschrieben habe, migrieren:
Sie können beide Formate unterstützen:
%Vor%Dieses Schema ist auch beliebt und wird auch unterstützt:
%Vor%Subversion und Git unterscheiden sich sehr darin, wie sie Geschichte darstellen, Metadaten behalten und systemspezifische Probleme behandeln. Solche Unterschiede verursachen die meisten Fallstricke:
Fehlende Zusammenführung in Git:
Subversion speichert Informationen über durchgeführte Zusammenführungen als svn: mergeinfo-Eigenschaft für Dateien und Verzeichnisse. Bei der Konvertierung in Git gehen Informationen über Unterbaumverschmelzungen und Cherry-Picks verloren, da Git keine Möglichkeit hat, es darzustellen.
Siehe auch Nach "git svn clone" habe ich immer noch keine fantastische Branch-Merging-Commit?
Externe und Submodule:
Ergänzung zu @ Sundae Antwort : werfen Sie einen Blick auf SmartGit - dieses Tool kann svn: externals importieren. Es verwendet jedoch eine Datei eines speziellen Formats, das von anderen Git-Clients nicht unterstützt wird.
Leere Verzeichnisse:
Subversion behandelt Verzeichnisse als erstklassige Bürger, Git nicht - man muss eine Platzhalterdatei hinzufügen, um ein Verzeichnis bei der Konvertierung zu behalten. git-svn versucht, dies mit dem externen Speicher "unhandled log" zu behandeln, aber das funktioniert nur, wenn Sie nach der Konvertierung git-svn verwenden.
svn: ignore und .gitignore, svn: eol-style / mime-type und .gitattributes:
git-svn konvertiert Subversion-Eigenschaften nicht automatisch in entsprechende .gitattributes. Man muss einen bestimmten Befehl ausführen nach die Konvertierung, um Attribute hinzuzufügen - sowieso geht diese Information bei der Konvertierung verloren.
Arbitrary Subversion Eigenschaften:
Alle benutzerdefinierten Datei- und Revisionseigenschaften gehen verloren, wenn das Subversion-Repository in das Git-Repository konvertiert wird.
Sehen Sie sich SubGit an. Es meistert die meisten Fallstricke gut, andere sollen in weiteren Versionen behoben werden.
SubGit ist ein unternehmensweites Migrationswerkzeug. Man kann es als One-Shot-Konvertierungs-Dienstprogramm verwenden, aber im Allgemeinen ist es kontinuierliche Subversion und Git-Synchronisierungs-Tool. Weitere Informationen finden Sie auf der Dokumentationsseite .