Wie benutzt SVN tatsächlich Mergeinfo?
Ich habe schon lange von den Konflikten mit dem Merge-Konflikt von svn gehört.
Ich war erleichtert, dachte ich, als ich erfuhr, dass vor einigen Releases eine Funktion namens mergeinfo implementiert wurde. Es schien fast so, als ob die Einführung es svn erlauben würde, genügend Informationen zu haben, um seine Verschmelzungsprobleme zu lösen, wann immer sie auftauchten. Bis ich in die folgende Situation kam:
Skriptbeispiel des obigen Graphen:
%Vor% Wenn svn den Verlauf der einzelnen Zweige protokolliert, warum kann es dann nicht verstehen, dass b.txt unverändert @ branch A ?
Wenn es das nicht herausfinden kann, welche tatsächliche Verwendung macht svn von mergeinfo ?
Wenn svn nicht in der Lage ist, sich mit diesem Problem zu befassen, wäre es nicht möglich, ein Tool zu erstellen, das mir hilft (nämlich automatisches Auflösen dieser Art von Problemen.)? Ich denke, vielleicht würde man schon existieren?
Danke
3 Antworten
Es gibt zwei Arten von Zusammenführungen in Subversion:
- Drei-Punkt-Merges
- Zwei-Punkt-Merges (auch Reintegrations-Merging genannt)
Nehmen wir an, Sie arbeiten an einer Leitung, und Sie haben eine bestimmte Funktion, die erledigt werden muss. Sie erstellen einen Feature A Zweig. Während Sie an der Funktion arbeiten, möchten Sie, dass die Arbeit, die Sie an trunk ausführen, in Feature A aufgenommen wird, damit Sie mit dem Schritt mithalten können, was alle anderen tun. Subversion wird eine Dreipunkt-Zusammenführung verwenden.
Subversion wird den Unterschied zwischen Stamm- und Zweigmerkmal A von dem Punkt an betrachten, an dem der Zweig aufgetreten ist. Der jüngste gemeinsame Vorfahre. Es berücksichtigt dann alle Änderungen an Feature A, das durchgeführt wurde (das Sie nicht berühren möchten), sowie die Änderungen im Code, die auf dem Stamm ausgeführt werden.
Subversion wird dann die Änderungen auf dem Stamm zusammenführen, ohne die Änderungen zu überschreiben, die an dem Zweig vorgenommen wurden. Standard-Merge-Prozedur, und Subversion macht das ziemlich gut.
Wo kommt svn:mergeinfo rein? Sie möchten nicht zweimal die gleichen Änderungen zusammenführen, sodass Subversion die Änderungen mit der Eigenschaft svn:mergeinfo verfolgt. Wenn Subversion erkennt, dass die Änderung in der Amtsleitung aus Revision 5 bereits zusammengeführt wurde, wird diese Änderung nicht erneut eingefügt. Es ist sehr gut damit.
Nun sind Sie mit Ihrer Funktion fertig und möchten, dass diese Änderungen wieder in den Stamm eingefügt werden. Sie führen eine letzte Verbindung von Zweig zu Zweig durch, übernehmen diese Änderungen und gehen nun vom Zweig Feature zurück in den Stamm über.
Hier ist ein kleines Problem. Wir haben verfolgt, was wir vom Stamm in den Feature-Zweig über svn:mergeinfo zusammengeführt haben. Da wir jedoch nicht vom Feature-Zweig zum Trunk übergegangen sind, gibt es dort kein svn:mergeinfo . Wenn wir einen normalen Drei-Punkt-Merge vom Feature-Zweig in den Trunk versuchen, wird der Trunk annehmen, dass alle Änderungen im Feature-Zweig wieder in den Trunk zusammengeführt werden sollen. Viele dieser Features sind jedoch Trunk-Änderungen, die zusammengeführt wurden.
Ehrlich gesagt, möchten wir an dieser Stelle eine Zwei-Punkt-Fusion durchführen. Wir möchten, dass sowohl trunk als auch der Feature-Zweig genau übereinstimmen, sobald wir die Zusammenführung durchgeführt haben. Schließlich haben wir Trunk jetzt regelmäßig in den Feature-Zweig zusammengeführt. Was wir tun wollen, ist, diese Merkmale wieder in den Kofferraum zu integrieren. Somit ist der Stamm der gleiche wie der Feature-Zweig.
Vor Subversion 1.8 müssten Sie eine Reintegrationszusammenführung erzwingen, indem Sie svn merge --reintegration ausführen. Nun wird Subversion den Merge-Verlauf betrachten und herausfinden, wann eine Reintegrations-Merge durchgeführt werden sollte.
Jetzt ist hier der schwierige Teil. Sehen Sie sich die Revisionsnummern genau an. Diese werden sehr, sehr wichtig sein!
- Revision 10 : Ich habe meine letzten Änderungen in Trunk vorgenommen und muss diese in den Feature-Zweig zusammenführen.
-
Revision 11 : Ich führe Trunk in den Zweig Feature ein.
svn:mergeinfozeigt an, dass der gesamte Stamm von Revision 1 bis Revision 10 im Feature-Zweig liegt. Da die letzte Änderung am Stamm die Revision 10 ist, macht das vollkommen Sinn. - Revision 12 : Ich füge Revision 11 der Feature Branch in trunk zusammen. Dies ist eine Reintegration Zusammenführung. Danach sollte das, was im Feature-Zweig ist und was im Trunk ist, perfekt übereinstimmen.
Nun, hier ist der Kicker!
- Revision 13 : Ich mache noch eine Änderung im Stamm.
Nun möchte ich das in meinen Feature-Zweig (Erstellung von Revision 14) einbinden. Nun, was sagt der svn:mergeinfo im Feature-Zweig? Es besagt, dass der Stamm von Revision 1 bis Revision 10 in den Feature-Zweig integriert wurde. Revision 12 und Revision 13 von trunk wurden jedoch nicht durchgeführt. Daher wird Subversion Revision 12 und Revision 13 wieder in den Zweig Feature einfügen.
Aber warte eine Sekunde!
Revision 12 auf trunk war meine Zusammenführung aller Änderungen in meinem Feature-Zweig zurück in trunk! Das heißt, Revision 12 enthält bereits alle Änderungen, die ich in meinem Feature-Zweig vorgenommen habe. Wenn ich Revision 12 wieder in meinen Feature-Zweig einfüge, werde ich sagen, dass all diese Änderungen in Revision 12 auf trunk (die wirklich Änderungen am Feature-Zweig waren und in trunk zusammengeführt wurden) mit dem Feature-Zweig zusammengeführt werden müssen. Diese Änderungen wurden jedoch auch im Feature-Zweig vorgenommen. Können Sie Merge Conflict sagen? Ich wusste, dass du könntest!
Dafür gibt es zwei Möglichkeiten:
- Der empfohlene Weg : Sobald Sie Ihre Funktion wieder in den Stammzweig integriert haben, löschen Sie den Zweig. Verschließe es. Benutze es nie wieder. Nicht anfassen! Das ist nicht so schlimm wie es klingt. Nach der Reintegration werden Ihr Trunk und dieser Feature-Zweig trotzdem übereinstimmen. Das Löschen und Wiederherstellen der Verzweigung aus dem Stamm ist nicht so schlimm.
-
Der heikle Weg, der funktioniert Was wir tun müssen, ist Subversion zu denken, dass Revision # 12 (oder Reintegrationsänderungen) bereits in unseren Feature-Zweig integriert wurde.Wir könnten mit der
svn:mergeinfo-Eigenschaft fuzz machen. Und ich mache genau das. Wo estrunk:1-11sagt, würde ich es manuell intrunk:1-12ändern.
Das ist knifflig, aber viel zu knifflig und riskant, weil Subversion bereits eine Möglichkeit bietet,% code_de zu manipulieren, ohne sie manuell zu ändern.
Es wird nur ein Datensatz zusammengeführt.
%Vor% Dies ändert die svn:mergeinfo im Feature-Zweig, ohne den tatsächlichen Inhalt der Dateien zu beeinflussen. Es findet keine echte Zusammenführung statt, aber Subversion weiß nun, dass sich die Revision 12 der Amtsleitung bereits im Feature-Zweig befindet. Sobald Sie das getan haben, können Sie den Feature-Zweig wiederverwenden.
Sehen Sie sich nun Ihr Diagramm an: Wenn Sie Zweig B in Zweig A zusammengeführt haben, haben Sie alle Änderungen von B in A zusammengeführt, und svn:mergeinfo hat dies nachverfolgt. Wenn Sie Zweig B wieder in Zweig A zusammenführen, haben Sie bereits alle Änderungen von Zweig B in Zweig A, und Sie möchten nicht, dass diese Änderungen wieder in Zweig B übernommen werden. Sie hätten eine Reintegration
Wenn wir nun den Zweig A für weitere Änderungen verwenden wollen:
%Vor% Ich hoffe, dies erklärt ein wenig, wie svn:mergeinfo funktioniert, warum Sie wissen müssen, ob Sie die normale Drei-Punkt-Zusammenführung im Vergleich zur Zweipunkt-Reintegrations-Zusammenführung verwenden und wie Sie eine Verzweigung reaktivieren können nachdem Sie eine Reintegrationszusammenführung durchgeführt haben.
Solange Sie das im Hinterkopf behalten, funktioniert das Zusammenfügen von Subversion ziemlich gut.
Zuallererst ist die einfache Antwort, dass die Situation, die Sie präsentieren, gut funktioniert, wenn Sie Subversion 1.8 verwenden. Das Beispielscript, das ich der Frage hinzugefügt habe, hat keinen Konflikt, wenn es mit Subversion 1.8 ausgeführt wird. Nur der Client muss aktualisiert werden, um diese Funktionalität zu erhalten.
Die längere Antwort hier ist, dass Sie mit älteren Versionen von Subversion wissen müssen, wann Sie die schlecht benannte Option --reintegrate verwenden müssen (1.8 stellt dies für Sie fest). Trotz des Namens --reintegrate ist nicht nur für, wenn Sie eine Verzweigung wieder in Ihren Stamm zu integrieren.
Eines der wiederkehrenden Probleme, die Menschen haben, ist, wenn sie Feature-Zweige verwenden, dass sie den Feature-Zweig wieder mit ihrem Stamm zusammenführen und dann den Zweig weiter verwenden möchten. Wie Davids Antwort in der Vergangenheit andeutet, gab es zwei Methoden, um damit umzugehen. Löschen Sie zuerst den Zweig und machen Sie ihn dann frisch. Zweitens machen nur Merges aufzeichnen. Julian Foad, einer meiner Mitsubishi-Entwickler, der auf dem Weg zu 1.8 war, erkannte, dass keine dieser beiden Techniken notwendig war. Er berichtete darüber in seiner Präsentation über die Fusion bei der Subversion Live 2012 Konferenz . Die Folien für seine Präsentation sind hier online verfügbar (beachten Sie, dass dies eine PDF aller Folien für die Konferenz ist, so dass es nicht gerade winzig ist), der Teil zu diesem Thema beginnt auf Seite 123.
Um seine Präsentation zusammenzufassen, besteht der typische Zweig der Feature-Verzweigung darin, eine Abzweigungsleitung zu erstellen. Nehmen Sie die Commits für Ihre Feature-Verzweigung vor und führen Sie sie regelmäßig von der Amtsleitung zu Ihrer Feature-Verzweigung zusammen, um sie mit der Amtsleitung zu synchronisieren, z. %Code%. Dann, wenn Sie bereit sind, zurück in den Trunk zu migrieren, machen Sie svn merge ^/trunk $BRANCH_WC . Jetzt sind Sie an dem Punkt angelangt, an dem Sie normalerweise Ihre Feature-Verzweigung löschen oder eine Nur-Datensatz-Zusammenführung durchführen mussten. Stattdessen hat Julian festgestellt, dass Sie den Zweig einfach weiter verwenden können, wenn Sie diese Regeln befolgt haben.
-
Jedes Mal, wenn Sie in die gleiche Richtung wie die letzte Zusammenführung zwischen den beiden Zweigen zusammenführen, verwenden Sie NICHT die Option
svn merge --reintegrate ^/branches/myfeature $TRUNK_WC. Behandle die Erstellung des Zweigs als Zusammenführung von diesem Erstellungsort. -
Jedes Mal, wenn Sie Richtungen ändern, die Sie zwischen den beiden Zweigen zusammenführen, verwenden Sie
--reintegratefür diese Zusammenführung.
In Ihrem speziellen Fall ändern Sie die Richtung, die Sie zusammengeführt haben. r7 geht von Zweig B in Zweig A über. r9 geht von Zweig A nach Zweig B. Wenn Sie also Ihre R9-Zusammenführung machen, müssen Sie --reintegrate verwenden. Diese Logik ist genau das, was Subversion für Sie mit 1.8 macht.
Schließlich empfehle ich das Zusammenführen zwischen Geschwisterzweigen nicht, wie Sie es hier tun. Viele einfache Fälle wie das, was Sie hier tun, werden gut funktionieren. Wenn Sie zum Beispiel eine Datei teilen ( --reintegrate , entfernen Sie einen Teil von file1 und einen anderen Teil von file2), werden Sie Probleme bekommen, wenn Sie versuchen, den letzten der beiden Feature-Zweige wieder in den Trunk ( vorausgesetzt, Sie haben die Aufteilung auf beide Zweige der Zweigstelle verschmolzen). Es ist am besten, das Zusammenführen auf zwei Zweige (Kind und Eltern) zu beschränken. Sie können Zweige von anderen Zweigen abzweigen und wieder zu ihren Eltern zusammenführen, bevor Sie zum Elternteil der Eltern und so weiter gehen und in Ordnung sein. Wir möchten, dass auch solche Dinge in Zukunft richtig funktionieren, aber dies ist die Situation, wie sie jetzt in 1.8 steht (viel besser als in der Vergangenheit, aber nicht so gut, wie wir es gerne hätten) / p>
Sie haben die Mergeinfo-Bedeutung und Verwendung missverstanden - sie enthält nur (für diesen Knoten) fusionierte Revisionen und Merge-Ursprünge, um Revision nicht zweimal zusammenzuführen, nichts über Inhalt
Tags und Links merge svn version-control mergeinfo