Welche Revisionskontrolle hat die beste Zusammenführungs-Engine? [geschlossen]


8

Wenn es um das Zusammenführen geht, hat jede Steuerungsversion ihre Engine, um dies zu tun. Konflikte sind unvermeidlich, aber die Frage ist, welche Revisionskontrolle die beste KI hat, um Konflikte zu vermeiden.

Ist es möglich, so etwas zu messen?

Insbesondere denken wir darüber nach, zu GIT zu wechseln, weil es einen netten Hype und ein Gerücht gibt, das Konflikte besser handhabt ...

Jeder Kommentar wird geschätzt ...


10
Letztendlich kann kein VCS "enge Zusammenschlüsse" gut bewältigen, ohne etwas Außerirdisches zu tun. Wenn eine Person einer Routine, die in eine Richtung geht, Logik hinzufügt und eine andere Person etwas Ähnliches - aber völlig anderes - tut, müssen sich die Menschen engagieren.
Peter Rowell

1
Theoretisch könnten Zusammenführungsalgorithmen sehr gut sein, wenn sie den Quellcode tatsächlich kompilieren. Scheint irgendwie da draußen zu sein, aber es ist wahrscheinlich nur eine Frage der Zeit.
Karl Bielefeldt

1
@ Karl: wie? Kompilieren Sie welchen Quellcode - wenn ich eine Zeile in x = 1 ändere und mein Kollege dieselbe Zeile in x = 2 ändert, wie wird der Compiler dann herausfinden, welche Zeile angesichts der restlichen zusammengeführten Commits "korrekt" ist?
Gbjbaanb

1
@gbj, Sie werden menschliches Eingreifen niemals ganz vermeiden können, wie Ihr Beispiel beweist. Das Kompilieren des Quellcodes kann jedoch das Zusammenführen von Variablen oder Methoden oder das Ändern auf zwei funktional identische, aber textlich unterschiedliche Arten einfacher zusammenführen.
Karl Bielefeldt

Einige der "menschlichen" Faktoren konnten nicht getestet werden. Die Menschen wissen, was sie zu produzieren versuchen, sodass der Konflikt durch Kompilieren und Ausführen von Tests gelöst werden kann. Unit-Tests sollten so klein sein, dass ein paar Aktualisierungen derselben Methode in wenigen Durchgängen möglich sind. Wenn der Test in beide Richtungen erfolgreich ist, müssen Menschen einbezogen werden, wenn das Zusammenführungssystem feststellt, dass es zu viele Variationen gibt Die Kompilierung ist nicht nachvollziehbar. Menschen müssen einbezogen werden.
Quaternion

Antworten:


21

Ich denke nicht, dass dies die richtige Frage ist.

Das Problem ist, dass es viele Eckfälle gibt und "intelligente" Algorithmen zum Zusammenführen sich selbst dazu verleiten können, zu glauben, dass sie die Zusammenführung korrekt durchgeführt haben, obwohl sie Ihren Code tatsächlich vollständig verschlungen haben. Wenn Sie Glück haben, führt eine so schlechte Zusammenführung zu einem Fehler bei der Kompilierung. Wenn Sie Pech haben, kann dies zu einem subtilen Fehler führen, dessen Aufspüren ewig dauert.

Git verwendet einen ziemlich einfachen Zusammenführungsalgorithmus und wirft die Hände hoch und bittet um Hilfe, wenn es die Zusammenführung nicht durchführen kann. Meiner Meinung nach ist dies genau das , was Ihr Versionskontrollsystem tun soll. Die Menge an Trauer, die Ihnen dadurch erspart bleibt, ist die Zeit wert, die Sie benötigen, um Konflikte manuell zu beheben. (Wenn bei einer Zusammenführung Konflikte auftreten, listet git die in Konflikt stehenden Dateien in der automatisch generierten Festschreibungsnachricht für Sie auf. Dies ist sehr praktisch, um Fehler zu finden, wenn Sie Ihren Codeverlauf durchgehen.)


6

Es wurde gesagt, dass der beste Algorithmus die Patch-Algebra von Darcs ist. Codeville hat auch einen interessanten Algorithmus in der Entwicklung.
Aus praktischen Gründen ist jedoch jedes Tool geeignet, das eine Drei-Wege-Zusammenführung verwendet. Dazu gehören Git (mit Varianten), Quecksilber, Basar und viele externe Tools (bemerkenswerte Ausnahmen: Opendiff und Kaleidoskop auf dem Mac). Mit hoher Wahrscheinlichkeit verwenden Sie also bereits die besten Optionen. Wie @Peter bemerkte, gibt es Fälle, in denen kein Algorithmus Ihnen helfen kann.


4
Es gibt subtile Unterschiede zwischen 3-Wege-Zusammenführungsalgorithmen, z. B. welcher gemeinsame Vorfahr ausgewählt wird, und in der Qualität der 2-Wege-Unterschiede, die sie beim Abgleichen von Linien verwenden, aber Sie haben Recht, dass die Fälle, in denen dies einen praktischen Unterschied macht sind relativ selten.
Karl Bielefeldt

TMK Mercurial hat keine echte 3-Wege-Zusammenführung, Sie müssen 2 Zwei-Wege-Zusammenführungen durchführen
TheLQ

@ TheLQ die Dokumente sagen etwas anderes: mercurial.selenic.com/wiki/MergeProgram, aber sie sind ein bisschen knapp bei den Details
Agos

@TheLQ - Es gibt einen großen Unterschied zwischen einem Drei-Wege-Diff und einem Drei-Wege-Zusammenführen . Ein Drei-Wege-Unterschied besteht aus zwei zusammenzuführenden Dateien und einem gemeinsamen Vorfahren, wobei Sie mit dem gemeinsamen Vorfahren sehen können, wie die beiden Quellen voneinander abweichen. Eine Drei-Wege-Zusammenführung würde einen Vier-Wege-Unterschied , drei divergierende Dateien und ihren gemeinsamen Vorfahren erfordern .
Mark Booth

3

Ich benutze Git und Quecksilber, aber Ihre Frage erinnert mich an die Patch-Theorie der Darcs. Sie werden für dieses Wochenende Hausaufgaben lesen müssen.

PD: Frag mich nicht nach der Theorie der Patches, das ist sehr komplex für mich :)


Interessantes, denken Sie daran, dass SVN durch Anwenden von Patches zusammengeführt wird. Ein vollständiger Patch-Algorithmus, der sowohl den Buchstaben r als auch m auf dasselbe Wort anwendet, führt jedoch nicht zum richtigen Ergebnis. In diesem Fall müssen Sie noch menschlich eingreifen.
Gbjbaanb

3

Es heißt Human Revision Control. (Human Merging Engine)

Wir verwenden Seapine Surround und es macht größtenteils eine gute Arbeit beim Zusammenführen, aber die einzige Möglichkeit, Zusammenführungskonflikte zu beheben, die die Quellcodeverwaltung nicht ausführen kann, ist menschliches Eingreifen.

Mein Rat lautet also:

Versuchen Sie, schnell zusammenzuführen. Ein Albtraum war eine Niederlassung, die seit fast zwei Jahren nicht mehr zur Hauptstrecke zurückkehrte. Beim Zusammenführen mussten viele Konflikte gelöst werden. Ein Entwickler erhielt den Spitznamen "Merge Master", nachdem er viel Zeit damit verbracht hatte, Merge-Probleme zu beheben.

Seien Sie vorsichtig mit automatisch generiertem Code von Assistenten usw. Manchmal kann das Zusammenführen sehr schwierig sein, insbesondere wenn zwei Zweige automatisch Änderungen an derselben Datei generieren.

Versuchen Sie, die Entwicklung zu kontrollieren. Wenn Entwickler A die Codedateien X und Y auseinander reißt, ist es für Entwickler B wenig sinnvoll, an X und Y in einem anderen Zweig zu arbeiten. Ein Teil des Zusammenführungsmanagements besteht darin, zu versuchen, zu steuern, was geändert wird, um das Potenzial für Zusammenführungskonflikte zu vermeiden.

Dies bedeutet nicht, dass 2 Entwickler nicht in zwei verschiedenen Zweigen an derselben Datei arbeiten können. Wenn 1 Entwickler Methode A und ein anderer Methode B hinzufügt, sollte die Zusammenführung problemlos erfolgen.

Am Ende wird es immer Konflikte geben, die menschliches Eingreifen erfordern. Wenn Sie diese auf ein Minimum beschränken, erzielen Sie die besten Zusammenführungsergebnisse.


2
IMHO Automatisch generierte Dateien sollten nicht in der Versionskontrolle sein. Nur die Dateien, mit denen sie generiert werden.
Calmarius

2

Die perfekte Zusammenführungs-Engine würde die Semantik der zusammengeführten Datei verstehen: Sie analysiert und versteht den Quellcode. Ich muss noch eine solche Merge Engine / Versionskontrolle sehen ...

Die meisten Zusammenführungswerkzeuge führen Dateien als Text zusammen. Ich würde mich also niemals blind auf sie verlassen. Es ist immer eine gute Idee, die Änderungen zu überprüfen, bevor Sie sie in Ihre Niederlassung übertragen.

Wir verwenden Perforce, das nicht automatisch zusammengeführt wird. Wenn sich die Quelldatei relativ zur gemeinsamen Basis ändert, wird angegeben, dass die Zieldatei aufgelöst werden muss, auch wenn kein Konflikt vorliegt. Also öffne ich das Merge-Tool, um schnell zu überlegen, ob die Hunks passen (und ein grobes Bild davon zu bekommen, was andere Peers tun). Meistens passen sie und akzeptieren das Ergebnis.

Ich habe auch die Änderungsbenachrichtigungen der Hauptleitung abonniert, damit ich die Änderungen so früh wie möglich in meinem Zweig zusammenführe, um später Probleme zu vermeiden.


1

Ähm ...

Wenn Sie mercurial (und git, da bin ich mir ziemlich sicher) verwenden, wählen Sie Ihre Merge-Engine aus. Standardmäßig ist es kdiff3, aber Sie können alles verwenden, was Sie möchten (unvergleichlich, p4merge usw.).

AFAIK Die Merge Engine und VCS sind oft völlig getrennt , ähnlich wie Ihr Compiler und Ihr Texteditor. Nehmen wir zum Beispiel XML oder Code. Sie möchten, dass verschiedene Dinge zusammengeführt werden. Sie funktionieren nicht auf die gleiche Weise und können daher nicht auf die gleiche Weise zusammengeführt werden.

Wenn Sie die Versionskontrolle wechseln, weil Sie ein besseres Zusammenführungstool benötigen, das Sie aus den falschen Gründen ausführen, sollten Sie die Versionskontrolle nur wechseln, wenn die jetzt verwendete nicht zu Ihrem Prozess passt (oder eine andere würde) erlauben Sie einen besseren Prozess).


1
Jedes VCS verfügt über einen integrierten Zusammenführungsalgorithmus, den es verwendet. Die Zusammenführungswerkzeuge, auf die Sie verweisen, werden nur verwendet, wenn Konflikte vorliegen, die die interne Engine nicht lösen kann. Die Frage ist, welcher VCS-Zusammenführungsalgorithmus der "beste" ist, obwohl ich nicht sicher bin, ob dies eine genau definierte Frage ist. Einige Leute definieren es als "produziert die wenigsten Konflikte, die gelöst werden müssen"; Ich würde sagen, gibt die wenigsten Fehler.
ebneter

1
Ich bin mir ziemlich sicher, dass mercurial tatsächlich seine Diff-Tools hinter den Kulissen verwendet. Es gibt eine Einstellung, mit der Sie sie irgendwo ändern können. Alle von mir erwähnten Diff-Tools verfügen über einen 3-Wege-Zusammenführungsmodus (nicht nur einen Diff-Modus), und p4merge ist definitiv das Werkzeug, das notgedrungen verwendet wird, wenn eine Kollision erkannt wird. Ich denke, das VCS selbst hat nur einen Kollisionserkennungsalgorithmus (dh Sie haben dieselbe Datei an derselben Stelle geändert), der ein Vorläufer für das Zusammenführen ist.
Ed James

Standardmäßig verwendet Mercurial einen einfachen Drei-Wege-Zusammenführungsalgorithmus. Ja, das können Sie jedoch überschreiben. Sie können die integrierte Zusammenführung in den meisten VCS-Tools überschreiben. AFAIK, alle verwenden jedoch einen internen Zusammenführungsalgorithmus, um nach Konflikten zu suchen, und das ist hier wirklich ein wichtiger Punkt. Wenn der interne Zusammenführungsalgorithmus Ihres VCS zu clever ist, findet er möglicherweise keinen Konflikt, wo er sollte.
ebneter

In einem DVCS erwarte ich, dass bei jeder Zusammenführung eines Zweigs alle Dateien ausgeführt werden, die in beiden Zweigen über das Hauptzusammenführungstool bearbeitet werden. Sie müssten nicht nach einem Zusammenführungskonflikt suchen. Nehmen Sie einfach an, dass es einen gibt. Wenn dies nicht der Fall ist, haben Sie nichts verloren. Ich würde mir vorstellen, dass dies auch für ein Standard-VCS gilt.
Ed James

Was meinst du mit "Hauptzusammenführungstool"? Der Standardalgorithmus oder der von Ihnen angegebene? Wenn Sie letzteres meinen, so fair wie ich weiß, funktioniert keiner von ihnen so. Jedes mir vertraute VCS verwendet seinen internen Algorithmus zum Zusammenführen und ruft das vom Benutzer ausgewählte Tool nur auf, wenn ein Konflikt vorliegt. Beachten Sie, dass Sie bei einigen VCSs wie git zwischen mehreren integrierten Strategien wählen können und einige VCSs über ziemlich ausgefeilte interne Algorithmen verfügen. Dies führt jedoch zu dem Problem, das ich in meiner Antwort beschrieben habe.
ebneter

1

Konflikte sind unvermeidlich

Wie gut ein VCS mit Konflikten innerhalb einer Datei umgeht, ist meiner Meinung nach etwas überbewertet. Zum einen ist der beste Weg, mit solchen Konflikten umzugehen, sie überhaupt nicht zu haben. Wenn Sie Ihre Software gut berücksichtigen und Aufgaben mit Bedacht aufteilen, werden Konflikte innerhalb eines Dateiclusters (geschweige denn innerhalb einer Datei) erheblich reduziert. Machen Sie einen schlechten Job, z. B. werfen Sie eine zu viele Gottklassen ein oder eine gemeinsame Konfigurationsdatei, die jeder verwenden muss und mit der jeder herumspielen möchte, und Sie fragen nach Konflikten auf Dateiebene.

Zum anderen verwenden alle so ziemlich den gleichen (miesen) Algorithmus. Ein Beispiel: Eine Alpha-Version unseres Projekts hatte einen geringfügigen Speicherverlust. Es war eher ein Tropfen als ein Leck, und das Leck hörte am Ende der Initialisierungszeit auf. Eine Lösung wert, keinen Patch wert. Einer unserer Kunden "hat" das Problem "behoben" und das Freie am falschen Ort platziert. Das Problem wurde in der nächsten Version behoben. Dieser Kunde hat die neue Version zusammengeführt, anstatt einen vollständigen Ersatz (WTF?) Durchzuführen. Es gab keine Konflikte bei der Drei-Wege-Fusion; Die Aufrufe zur Befreiung waren gut voneinander isoliert. Jetzt lässt die Software den Kern fallen, weil sie doppelt frei ist.

Was in der Diskussion übersehen wird, ist, wie schwierig / zeitaufwändig / fehleranfällig es ist, Ihre Arbeit wieder in die Hauptzeile der Software zu integrieren.

In svn du

  • Übernehmen Sie die Änderungen in Ihren Zweig.
  • Führen Sie den Stamm in Ihren Zweig ein.
  • Wenn Sie ein großes Projekt haben, möchten Sie vielleicht eine Kaffeepause einlegen oder zum Mittagessen gehen.
  • Beten Sie, dass Sie bei Ihrer Rückkehr keine Baumkonflikte sehen.
  • Übernehmen Sie die Ergebnisse der Zusammenführung in Ihren Zweig.
  • Führen Sie Ihren Zweig in den Stamm ein.
  • Machen Sie noch eine Kaffeepause.
  • Beten Sie noch einmal, dass Sie bei Ihrer Rückkehr keine Baumkonflikte sehen.
  • Übernehmen Sie Ihre Änderungen wieder in den Kofferraum.
  • Schließen Sie Ihre Tür, um Konflikte mit Ihrem Kollegen zu vermeiden, der versucht hat, dasselbe zu tun.

Das sind viel viele nichtatomare Schritte, viel zu viele Stellen, an denen sich Fehler einschleichen können (Baumkonflikte sind einfach böse), und es dauert viel zu lange. Ich habe mehrere Projekte gesehen, die die Verwendung von Zweigen mit Subversion aufgegeben haben, hauptsächlich weil der Zusammenführungsprozess so zeitaufwändig und fehleranfällig war. Ich habe noch mehr Projekte gesehen, die größtenteils aus diesem Grund von Subversion gewechselt sind.


1

Es gibt eine kleine Testsuite namens merge-this, die das Revisionskontrollsystem mit realen Zusammenführungsszenarien vergleicht. Für jedes Szenario wird sichergestellt, dass ein VCS Folgendes korrekt ausführen kann:

  • Führen Sie den Zweig ohne Konflikte zusammen
  • Code erstellen, der kompiliert wird
  • Code erstellen, der sich korrekt verhält

Basierend auf der Anzahl der bestandenen Tests beim Zusammenführen scheint es zwei Leistungsstufen zu geben:

  1. Darcs, Git
  2. Basar, Mercurial

Je nachdem, welche Programmiersprachen Sie zusammenführen möchten, können die genauen Testergebnisse von Bedeutung sein. Auf der Website des Projekts finden Sie eine detaillierte Vergleichstabelle.



0

Ich habe IBM / Rational ClearCase verwendet und das Zusammenführen mehrerer Zweige ist einfach fantastisch. Läuft Ringe um Subversion. (Keine Erfahrung mit Git oder Quecksilber.)


Die Zusammenführung von hg ist gleich oder besser als cc. Ich habe beide benutzt.
Paul Nathan
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.