Tipps für die manuelle Zusammenführung von diverged Code

Question

Ich bin ziemlich gewöhnt an die Verwendung von Svn zum Verzweigen und Zusammenführen, normalerweise funktioniert das gut. Jedoch wurde eine Komponente in zwei Zweigen bearbeitet und nahm die Komponente im Grunde genommen in verschiedene Richtungen, so dass die automatische Zusammenführung nicht funktioniert und die Verwendung außerhalb des Vergleichs zeigt die Dateien als größtenteils unterschiedlich.

Ich habe versucht, einige der Dateien zusammenzufügen, aber die Ergebnisse, selbst wenn sie funktionieren, sind ziemlich entsetzlich.

Ich bin versucht, dem Geschäft zu sagen, dass dies einfach nicht getan werden kann. Ich kann sehen, dass sie frustrierend sind, da sie Modul + Funktion A arbeiten und Modul + Funktion B funktionieren, aber Modul + Funktion A + Funktion B macht einfach keinen Sinn, wie es steht. Zum Beispiel kann Feature A etwas entfernen, das eine Schlüsselkomponente in Feature B war.

Gibt es eine Möglichkeit zu versuchen, solchen Code zusammenzuführen? Oder ist Modul + A + B wirklich Modul + C?

Wir sahen das kommen, aber Feature A wurde in einem kürzeren Zeitrahmen benötigt als Feature B, das Teil eines lang laufenden Projekts war. Gibt es Möglichkeiten zu arbeiten, um dies zu vermeiden? Oder sind ihre Möglichkeiten, den Code so zu strukturieren, dass beide Features gut zusammenpassen?

Answer 1

Worüber Sie sprechen, ist im Wesentlichen versuchen, einen der Zweige zu rebasen. Es gibt Unterstützung dafür in some DVCSs, aber mir ist keine Unterstützung für diese Art von Sache in SVN bekannt.

Ihre beste Wette ist es, einen der Zweige (den, der am wichtigsten ist, jetzt zu haben) auszuwählen und es in die Hauptlinie zusammenzuführen, die ziemlich direkt sein sollte. In dem anderen Zweig müssen Sie die Änderungen aus dem Stamm ziehen und die Unterschiede abstimmen. In Anbetracht der Situation, die Sie beschrieben haben, wird dies mit ziemlicher Sicherheit nicht automatisch geschehen und Sie müssen möglicherweise ernsthaft darüber nachdenken, wie Sie diese Verzweigungsfunktionen implementieren von dem einen verschmolzen mit der Hauptlinie, aber das kostet die parallele Entwicklung: Dinge ändern sich.

Wie vermeiden Sie dies in der Zukunft? Frequent integration.

Wenn Sie zwei Teams haben, die jeweils eine Codebasis A erhalten und 6 Monate lang an verschiedenen Funktionen arbeiten, wird die Integration sehr schmerzhaft, da jeder Annahmen über A gemacht hat, dass sich das andere Team geändert hat. Auf der anderen Seite sollte sich jedes Team bei wöchentlichen oder monatlichen Integrationsaufbauten wesentlich stärker darüber im Klaren sein, welche Veränderungen der andere macht und die endgültige Integration sollte viel einfacher sein.

Aus diesem Grund sind Open-Source-Projekte oft gegen große Patches, veraltet schnell veraltet und niemand hat wirklich die Zeit, sie richtig zu überprüfen. Auf der anderen Seite, wenn Sie den gleichen Beitrag nehmen und es in eine Anzahl von kleinen verdaulichen Teilen aufteilen, die für sich allein stehen, ist Ihr Beitrag viel eher A) akzeptiert und B) richtig überprüft, so dass es nicht dazu führt ein endloser Strom von Defekten.

Answer 2

Nehmen Sie eine einzelne Datei, sagen Sie src1.c. Sie können ein Diamant-Diagramm konstruieren Beschreibung der Zusammenführung auf diese Weise:

Original src1.c 
     /  \ 
    /  \ 
    /   \ 
    b1 src1.c  b2 src1.c 
     \   /
     \  /
     \  /
     \ /
     merged src1.c 

Wo b1 bedeutet die erste Filiale Version und b2 bedeutet die zweite Zweig Version. Sie können parallele Diffs vergleichen (sagen Sie das zwischen der zusammengeführten Quelle und der b2-Version und b1 und dem Original). Dies kann helfen.