SVN, wie neue Baumkonflikte gelöst werden, wenn eine Datei in zwei Zweigen hinzugefügt wird

95

Beim Zusammenführen einiger Zweige (unter Verwendung von SVN 1.6.1), bei denen eine Datei zu beiden Zweigen hinzugefügt wurde (und dann in diesen separaten Zweigen bearbeitet wurde), tritt einer der neuen Baumkonflikte auf:

      C foo.txt
  >   local obstruction, incoming add upon merge

Ich brauche die Änderungen von beiden Zweigen, aber der Baumkonflikt gibt mir nicht die üblichen .working-, .merge-left- und .merge-right-Dateien - was aufgrund der Art des Konflikts verständlich ist. Es gibt einige dieser Konflikte, bei denen in jedem Zweig dieselbe Datei gelöscht wurde, die jedoch einfach zu lösen sind.

Wie kann ich dieses Problem beheben? Das SVN Redbean-Buch (für 1.6) behandelt diese Situation nicht.

svn merge tree-conflict

— DEfusion
quelle

40

Wie in einer älteren Version (2009) des Entwurfsdokuments "Tree Conflict" erwähnt:

XFAIL-Konflikt durch Zusammenführen von Add-Over-Version

Bei diesem Test wird eine Zusammenführung durchgeführt, bei der eine Datei ohne Verlauf in eine vorhandene versionierte Datei eingefügt wird .
Dies sollte ein Baumkonflikt in der Datei der local obstruction, incoming add upon mergeSorte ' ' sein. Feste Erwartungen in r35341.

(Dies wird in ClearCase übrigens auch als "böse Zwillinge" bezeichnet):
Eine Datei wird zweimal (hier zweimal "hinzugefügt") in zwei verschiedenen Zweigen erstellt, wobei zwei verschiedene Historien für zwei verschiedene Elemente erstellt werden, jedoch mit demselben Namen.

Die theoretische Lösung besteht darin, diese Dateien (mit einem externen Diff-Tool) manuell im Zielzweig ' B2' zusammenzuführen.

Wenn Sie noch am Quellzweig arbeiten, besteht das ideale Szenario darin, diese Datei aus dem Quellzweig zu entfernen und B1von B2zu wieder B1zusammenzuführen, um diese Datei sichtbar zu machen B1(Sie arbeiten dann an demselben Element).
Wenn eine Zusammenführung nicht möglich ist, da die Zusammenführung nur von B1bis erfolgt B2, ist für jede Zusammenführung eine manuelle Zusammenführung erforderlich B1->B2.

— VonC
quelle

2

Das Design-Dokument "

— Baumkonflikt

4

Das Lustige ist, dass selbst wenn beide hinzugefügten Dateien identisch sind, sie immer noch als widersprüchlich angezeigt werden. Dies sollte wirklich nicht als Konflikt gekennzeichnet werden.

— SantiBailors

1

@ SantiBailors So lustig, dass ich gerade sterbe. Sterben für meinen alten Freund git ...

— Winter

163

Ich habe einen Beitrag gefunden, der eine Lösung dafür vorschlägt . Es ist im Begriff zu rennen:

svn resolve --accept working <YourPath>

Dadurch werden die lokalen Versionsdateien als OK beansprucht.
Sie können es für einzelne Dateien oder ganze Projektkataloge ausführen.

— lukmdo
quelle

2

Danke, dies löst auch: C foo.txt> lokales Hinzufügen, eingehendes Hinzufügen beim Update

— Lazysoundsystem

5

danke, es hat auch bei mir funktioniert, aber ich musste das tun: svn entschlossen - akzeptiere die Arbeit FILENAME

— ajacian81

5

Ja, du brauchst einen Dateinamen. Es akzeptiert '.' (das aktuelle Verzeichnis). Ich musste dies auch rekursiv tun, um: "svn auflösen - akzeptieren arbeiten - rekursiv." löst alles zugunsten Ihrer Arbeitskopie (gefährlich! Sie können die Änderungen anderer Leute wegblasen, wenn Sie dies tun, wie immer, wenn Sie Konflikte lösen)

— Harry Wood

Ich verwende einen Alias, den ich erstellt habe, um alle Dateien mit Baumkonflikten aufzulisten: alias mtc='stat | awk "BEGIN { FS=\" \" } /^.{6}C/ { print \$NF }"' Dann kann ich diesen als Argument für den Auflösungsbefehl verwenden, wie folgt: svn resolve --accept working $(mtc)

— Earl Jenkins

1

In der Tat müssen Sie auch die Ressource angeben, zB: svn resolve --accept working path/index.html

— Tomasz Kuter

9

Was ist, wenn die eingehenden Änderungen die gewünschten sind? Ich kann svn resolve nicht ausführen - akzeptiere ihre voll

SVN-Auflösung - Basis akzeptieren

— Gabriel FT Gomes
quelle

4

Ich glaube, ich habe die Frage falsch verstanden. 'base' ist in der Tat gleichbedeutend mit 'thems-full', wenn 'svn resolve' verwendet wird, aber es löst Ihr Problem nicht. Stattdessen habe ich es in zwei Teile geteilt: 1) Lösche mein lokales Konfliktverzeichnis (oder meine Datei), 2) Zusammenführen. Dies sollte ohne Konflikte ablaufen, und da "die eingehenden Änderungen die gewünschten sind", würde ich mich nicht um die gelöschten Elemente kümmern

— Gabriel FT Gomes

2

Ich habe es gerade geschafft, mich ziemlich gründlich einzuklemmen und zu versuchen, den obigen Ratschlägen von user619330 zu folgen. Die Situation war: (1): Ich hatte einige Dateien hinzugefügt, während ich an meinem ersten Zweig, branch1, arbeitete. (2) Ich habe einen neuen Zweig erstellt, Zweig2 für die weitere Entwicklung, ihn vom Trunk abzweigen und dann meine Änderungen von Zweig1 zusammenführen. (3) Ein Mitarbeiter hatte meine Mods von Zweig1 in seinen eigenen Zweig kopiert und weitere Mods hinzugefügt. und dann wieder zum Kofferraum verschmolzen; (4) Ich wollte jetzt die neuesten Änderungen von Trunk in meinem aktuellen Arbeitszweig, Zweig2, zusammenführen. Dies ist mit SVN 1.6.17.

Die Zusammenführung hatte Baumkonflikte mit den neuen Dateien, und ich wollte die neue Version aus dem Trunk, in dem sie sich unterschieden. Daher habe ich von einer sauberen Kopie von branch2 einen SVN-Löschvorgang für die in Konflikt stehenden Dateien durchgeführt und diese branch2-Änderungen festgeschrieben (wodurch eine temporäre Version erstellt wurde) Version von branch2 ohne die fraglichen Dateien), und dann habe ich aus dem Trunk zusammengeführt. Ich habe dies getan, weil ich wollte, dass der Verlauf mit der Trunk-Version übereinstimmt, damit ich später keine Probleme mehr habe, wenn ich versuche, wieder zum Trunk zusammenzuführen. Das Zusammenführen verlief einwandfrei, ich habe die Trunk-Version der Dateien erhalten, svn st zeigt alles in Ordnung an, und dann habe ich beim Versuch, die Änderungen zwischen dem zuvor vorgenommenen Löschen und dem Hinzufügen aus dem Zusammenführen zu übernehmen, weitere Baumkonflikte festgestellt. Habe eine SVN-Lösung der Konflikte zugunsten meiner Arbeitskopie (die jetzt die Trunk-Version der Dateien hatte) durchgeführt und sie zum Festschreiben gebracht.

Nun, nein. Ein Update einer anderen Kopie von branch2 führte zur alten Version der Dateien (Pre-Trunk Merge). Jetzt habe ich zwei verschiedene Arbeitskopien von branch2, die angeblich auf dieselbe Version aktualisiert wurden, mit zwei verschiedenen Versionen der Dateien, und beide bestehen darauf, dass sie vollständig auf dem neuesten Stand sind! Das Auschecken einer sauberen Kopie von branch2 führte zur alten Version (Pre-Trunk) der Dateien. Ich aktualisiere diese manuell auf die Trunk-Version und schreibe die Änderungen fest, gehe zu meiner ersten Arbeitskopie zurück (von der ich die Trunk-Änderungen ursprünglich eingereicht hatte), versuche, sie zu aktualisieren, und erhalte jetzt einen Prüfsummenfehler für die betreffenden Dateien. Blasen Sie das betreffende Verzeichnis weg, erhalten Sie eine neue Version per Update, und schließlich habe ich eine gute Version von branch2 mit den Trunk-Änderungen. Ich hoffe. Vorbehalt Entwickler.

— Dewtell
quelle