SVN, wie neue Baum Konflikte zu lösen, wenn die Datei auf zwei Zweige hinzugefügt wird

Question

Beim Zusammenführen ein paar Zweige (mit SVN 1.6.1), wo eine Datei auf beiden Zweigen hinzugefügt wurde (und arbeitete dann in diesen getrennten Zweigen auf) Ich bin immer eine der neuen Baum Konflikte:

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

ich brauche die Änderungen aus beiden Zweigen, aber der Baum Konflikt gibt mir nicht die üblichen .working, .merge-links & .merge-Rechts-Dateien - die aufgrund der Natur des Konflikts verständlich ist. Es gibt ziemlich viele dieser Konflikte, und diejenigen, bei denen ein Lösch der gleichen Datei auf jedem Zweig aufgetreten ist, aber sie sind einfach zu lösen.

Wie kann ich dieses Problem beheben? Das SVN redbean Buch (für 1.6) nicht über diese Situation abdecken.

Answer 1

Wie bereits in einer älteren Version erwähnt (2009) der "Baum Conflict" design Dokument:

  

XFAIL Konflikt von merge von hinzufügen über versioniert Datei

     

Dieser Test eine Zusammenführung macht die bringt eine Datei zusätzlich ohne Geschichte auf eine   versionierte Datei .
  Dies sollte ein Baumkonflikt auf der Datei der ‚local obstruction, incoming add upon merge‘ Sorte sein. Feste Erwartungen in r35341.

(Dies wird auch als „schlechte Zwillinge“ in Clearcase durch die Art und Weise genannt):
eine Datei zweimal erstellt (hier „added“ zweimal) in zwei verschiedenen Zweigen, zwei unterschiedliche Geschichten für zwei verschiedene Elemente, aber mit dem gleichen Namen zu schaffen.

Die theoretische Lösung ist, um manuell die Dateien (mit einem externen Diff-Tool) in der Zielmietstation ‚B2‘ fusionieren.

Wenn Sie immer noch auf dem Quellzweig sind arbeiten, wäre das ideale Szenario, dass die Datei von der Quelle Zweig B1 zu entfernen verschmelzen zurück von B2 um B1 die Datei sichtbar auf B1 zu machen (Sie werden dann auf der Arbeit gleiches Element).
Wenn ein Merge zurück nicht möglich ist, weil verschmilzt tritt nur von B1 B2, dann eine manuelle Zusammenführung wird notwendig sein, für jede B1->B2 verschmilzt.

Answer 2

fand ich eine Post eine Lösung darauf hindeutet, für dass . Es geht darum, zu laufen:

svn resolve --accept working <YourPath>

, die die lokale Version Dateien als OK behaupten.
Sie können es für einzelne Dateien oder ganze Projektkataloge ausgeführt werden.

Answer 3

  

Was passiert, wenn die eingehenden Änderungen sind die, die Sie wollen? Ich bin nicht in der Lage svn lösen --accept ihre voll

laufen

svn resolve --accept Basis

Answer 4

ich es geschafft, nur um mich verkeilen ziemlich gründlich user619330 Rat versuchen, oben zu folgen. Die Situation wurde: (1): Ich hatte einige Dateien hinzugefügt, während auf meinem ersten Zweig, branch1 arbeiten; (2) Ich habe eine neue Filiale, branch2 für die weitere Entwicklung, Verzweigung sie aus dem Kofferraum aus und dann in meinen Änderungen von branch1 Verschmelzung (3) Ein Mitarbeiter meiner Mods von branch1 seinen eigenen Zweig kopiert hatte, fügte hinzu, mods, und dann verschmolzen wieder mit dem Stamm; (4) Ich wollte nun die letzten Änderungen vom Stamm in meinen aktuellen Arbeitszweig, branch2 verschmelzen. Dies ist mit svn 1.6.17.

Die Zusammenführung hatte Baum Konflikte mit den neuen Dateien, und ich wollte die neue Version aus dem Kofferraum, wo sie unterschieden, so von einer sauberen Kopie von branch2 ich ein SVN der widersprüchlichen Dateien löschen habe, verpflichtet, diese branch2 Änderungen (also ohne dass die betreffenden Dateien eine temporäre Version von branch2 erstellen), und tat dann meinen merge aus dem Kofferraum. Ich tat dies, weil ich die Geschichte wollte die Stamm-Version übereinstimmen, so dass ich nicht mehr Probleme später haben, wenn sie versuchen in den Stamm zurückgehen. Merge ging gut, bekam ich die Stamm Version der Dateien, svn st alles ok zeigt, und dann traf ich mehr Baum Konflikte beim Versuch, die Änderungen zu übernehmen, zwischen dem lösche ich früher getan hatte, und das Add aus der Zusammenführung. Hat eine svn resolve der Konflikte zugunsten meiner Arbeitskopie (die jetzt den Stamm Version der Dateien hatte), und bekam es zu begehen. Alles sollte gut sein, nicht wahr?

Nun, nein. Ein Update von einer anderen Kopie von branch2 führte in der alten Version der Dateien (pre-Stamm merge). So, jetzt habe ich zwei verschiedene Arbeitskopien von branch2, aktualisierten angeblich auf die gleiche Version, mit zwei verschiedenen Versionen der Dateien, und beide darauf bestehen, dass sie auf dem neuesten Stand sind! Auschecken ergab eine saubere Kopie von branch2 in der alten (pre-Stamm) Version der Dateien. Ich aktualisiere diese manuell in der Stamm-Version und die Änderungen zu übernehmen, gehen Sie zurück zu meiner ersten Arbeitskopie (von dem mir der Stamm vorgelegt hatte ändert ursprünglich), versuchen Sie es zu aktualisieren, und jetzt einen Prüfsummenfehler auf den Dateien in Frage kommen. Brennen Sie das betreffende Verzeichnis entfernt, eine neue Version über Updates erhalten, und schließlich habe ich, was eine gute Version von branch2 mit den Änderungen vom Stamm sein sollte. Ich hoffe. Caveat Entwickler.