Portierung von GIT-Merging-Funktionen auf SVN?

Question

Ich habe mir die YouTube-Präsentation angesehen Technisches Gespräch: Linus Torvalds über Git vor ein paar Wochen und eine Bemerkung ist mir im Gedächtnis geblieben.

In dieser Präsentation (ca. Minute 33) sagt Linus etwas in der Art von "Manche Leute klonen ein SVN-Repository, führen ein Merging durch (=Kopfschmerzen in SVN) und pushen dann das Ergebnis zurück nach SVN.".

Der Gedanke, den ich habe, ist: Wenn das möglich ist, warum portieren wir dann nicht die großartigen Merge-Fähigkeiten von GIT und machen sie zu einem integralen Bestandteil von SVN?

Auf diese Weise haben wir eine großartige Erweiterung von SVN und müssen unsere Unternehmens-Repositories und die dazugehörigen Skripte, die mit allen möglichen Systemen zur Fehlerverfolgung und kontinuierlichen Integration verbunden sind, nicht migrieren.

Ich muss etwas übersehen haben. Was ist es?

Answer 1

Es gibt einen weiteren großen Unterschied zwischen SVN und GIT, abgesehen davon, dass das eine zentralisiert ist und das andere nicht. GIT verfolgt Inhalte, SVN verfolgt Dateien.

Wenn Sie einen Zweig in SVN zusammenführen, berechnet SVN die Änderungen, die Sie im Zweig vorgenommen haben, und überträgt diese auf den Stamm (oder was auch immer Ihr Zusammenführungsziel ist). Diese Änderungen werden dann über einen normalen Commit in das Repository übertragen und die Quellinformationen (Historie im Zweig) werden vergessen. In späteren SVN-Versionen (>=1.5) hat sich das Verhalten beim Zusammenführen verbessert, SVN merkt sich jetzt, welche Revisionen eines Zweiges zusammengeführt wurden und welche nicht, aber das Grundproblem besteht immer noch.

OTOH GIT wird Ihnen fröhlich in seinem Protokoll sagen, dass einige Zeilen Ihres Codes aus dem Zweig xyz stammen und dass sie in den Revisionen a, b und c des Zweigs geändert wurden. Das macht es extrem einfach, verrückte Dinge zu tun, wie z.B. einen Zweig zu erstellen, daran zu arbeiten, auf den Hauptzweig zu aktualisieren, etwas mehr Arbeit zu verrichten, in den Hauptzweig zusammenzuführen, den Zweig zu verzweigen, und so weiter, ohne Probleme.

UPDATE:

Unterm Strich: SVN und GIT sind einfach zu unterschiedlich in der Art und Weise, wie sie Änderungen verfolgen, als dass SVN-Merging so cool wie in GIT werden könnte, ohne GIT zu werden.

Answer 2

Beachten Sie den erwähnten Google Talk über Git (Sie können übrigens das Transkript auf Git Wiki lesen: LinusTalk200705Transkript ) fand vor Subversion 1.5 statt. Zu dieser Zeit hat Subversion einfach hat nicht gespeichert erforderlich für intelligente Git-ähnliche Zusammenführung Merge-Verfolgung Informationen (es sei denn, Sie haben svnmerge Erweiterung, oder SVK, ein (halb)verteiltes SCM auf Subversion).

Answer 3

Kennen Sie die verbesserte Zusammenführungsmöglichkeiten in Subversion seit 1.5? Es ist viel umfangreicher als früher. Seit ich auf 1.5 umgestiegen bin, hatte ich keine Probleme mehr mit dem Zusammenführen. Es würde mich interessieren, welche Funktionen GIT hat, die späteren Versionen von Subversion fehlen.

Answer 4

Git und SVN sind zwei völlig verschiedene Wege, um das gleiche Problem zu lösen. Der eine ist verteilt, der andere zentralisiert, so dass man den GIT-Code nicht einfach in SVN einfügen kann. Das wäre so, als würde man versuchen, JQuery in eine alte VB6-Anwendung zu integrieren.

Answer 5

Seit 2009 hat es mindestens eine Initiative gegeben, um svn merge zu "reparieren":

Siehe " Es ist an der Zeit, Subversion Merge zu reparieren ", Juli 2011 (obwohl die meisten Kommentare darauf drängen, mit Git zu arbeiten ;) )
Und siehe die Projektseite " Subversion NewMerge-Zusammenführung korrigiert ", was eine Änderung der wie der Merge verfolgt wird .
Allerdings scheint dieses Projekt noch keine Veröffentlichung hervorgebracht zu haben.