it-swarm.com.de

Warum bekomme ich in Subversion Baumkonflikte?

Ich hatte eine Feature-Verzweigung in meinem Stamm und führte regelmäßig Änderungen aus meinem Stamm in meiner Verzweigung zusammen, und alles funktionierte einwandfrei. Heute bin ich losgegangen, um den Zweig wieder in den Stamm zusammenzuführen, und alle Dateien, die meinem Stamm nach der Erstellung meines Zweigs hinzugefügt wurden, wurden als "Baumkonflikt" gekennzeichnet. Gibt es eine Möglichkeit, dies in Zukunft zu vermeiden?

Ich glaube nicht, dass diese richtig gekennzeichnet sind.

350
Greg

Ich fand die Lösung, indem ich den Link las, den Gary gab (und ich schlage vor, diesem Weg zu folgen).

Zusammenfassung zur Behebung des Baumkonflikts Festschreiben Ihres Arbeitsverzeichnisses Mit SVN-Client 1.6.x können Sie Folgendes verwenden:

svn resolve --accept working -R .

wo . ist das in Konflikt stehende Verzeichnis.

WARNING : "Festschreiben Ihres Arbeitsverzeichnisses" bedeutet, dass Ihre Sandbox-Struktur die ist, die Sie festschreiben. Wenn also Sie haben beispielsweise einige Dateien aus Ihrer Sandbox gelöscht. Diese werden auch aus dem Repository gelöscht. Dies gilt nur für das in Konflikt stehende Verzeichnis.

Auf diese Weise schlagen wir SVN vor, um den Konflikt zu lösen (--resolve), akzeptiere die Arbeitskopie in deiner Sandbox (--accept working), rekursiv (-R), beginnend mit dem aktuellen Verzeichnis (.).

Wenn Sie in TortoiseSVN mit der rechten Maustaste auf "Gelöst" klicken, wird dieses Problem behoben.

395
gicappa

In Subversion 1.6 wurden Baumkonflikte hinzugefügt, um Konflikte auf Verzeichnisebene abzudecken. Ein gutes Beispiel wäre, wenn Sie eine Datei lokal löschen und dann ein Update versucht, eine Textänderung in dieser Datei herabzusetzen. Eine andere Möglichkeit besteht darin, dass Sie eine Datei, die Sie gerade bearbeiten, in Subversion umbenennen, da dies eine Aktion zum Hinzufügen/Löschen ist.

CollabNets Subversion-Blog enthält einen großartigen Artikel über Baumkonflikte .

58
Gary.Ray

Meiner Erfahrung nach erstellt SVN einen Baumkonflikt, WENN ich einen Ordner lösche. Es scheint keinen Grund zu geben.

Ich bin der einzige, der an meinem Code arbeitet -> ein Verzeichnis löschen -> festschreiben -> Konflikt!

Ich kann es kaum erwarten, zu Git zu wechseln.

Ich sollte klarstellen - ich benutze Subclipse . Das ist wahrscheinlich das Problem! Ich kann es kaum erwarten, wieder zu wechseln ...

33
shmimpie

Ich weiß nicht, ob Ihnen das passiert, aber manchmal wähle ich das falsche Verzeichnis zum Zusammenführen und erhalte diesen Fehler, obwohl alle Dateien völlig in Ordnung sind.

Beispiel:

Führen Sie/svn/Project/branches/some-branch/Sources zu/svn/Project/trunk zusammen ---> Baumkonflikt

Führen Sie/svn/Project/branches/some-branch zu/svn/Project/trunk zusammen ---> OK

Dies mag ein dummer Fehler sein, aber es ist nicht immer offensichtlich, weil Sie denken, dass es etwas komplizierter ist.

28
Smarb

Was hier passiert, ist Folgendes: Sie erstellen eine neue Datei in Ihrem Trunk und führen sie dann in Ihrem Zweig zusammen. Beim Merge-Commit wird diese Datei auch in Ihrer Filiale angelegt.

Wenn Sie Ihren Zweig wieder in den Trunk einbinden, versucht SVN dasselbe erneut: Es wird angezeigt, dass eine Datei in Ihrem Zweig erstellt wurde, und es wird versucht, sie in Ihrem Trunk im Merge-Commit zu erstellen, aber sie ist bereits vorhanden! Dies erzeugt einen Baumkonflikt.

Um dies zu vermeiden, führen Sie eine spezielle Zusammenführung durch, eine Reintegration . Sie erreichen dies mit dem --reintegrate Schalter.

Sie können dies in der Dokumentation nachlesen: http://svnbook.red-bean.com/de/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Beim Zusammenführen Ihres Zweigs zurück zum Stamm unterscheidet sich die zugrunde liegende Mathematik jedoch erheblich. Ihr Feature-Zweig ist jetzt ein Mischmasch aus doppelten Amtsleitungsänderungen und Änderungen an privaten Zweigen, sodass kein einfacher zusammenhängender Änderungsbereich zum Kopieren vorhanden ist. Wenn Sie die Option --reintegrate angeben, werden Sie von Subversion aufgefordert, nur die für Ihren Zweig spezifischen Änderungen sorgfältig zu replizieren. (Und dies geschieht tatsächlich durch Vergleichen des neuesten Stammbaums mit dem neuesten Zweigbaum: Der resultierende Unterschied ist genau, dass sich Ihr Zweig ändert!)

Nach der Wiedereingliederung eines Zweigs ist es sehr ratsam, ihn zu entfernen, da es sonst immer wieder zu Baumkonflikten kommt, wenn Sie in die andere Richtung verschmelzen: vom Stamm zum Zweig. (Aus genau dem gleichen Grund wie zuvor beschrieben.)

Es gibt auch einen Weg, aber ich habe es nie ausprobiert. Sie können es in diesem Beitrag lesen: Wiedereingliederung von Subversion-Zweigen in v1.6

15
Gábor Angyal

Dies kann dadurch verursacht werden, dass nicht überall die gleichen Versionsclients verwendet werden.

Wenn Sie einen Client der Version 1.5 und einen Client der Version 1.6 für dasselbe Repository verwenden, kann dies zu Problemen dieser Art führen. (Ich wurde nur selbst gebissen.)

7
kaleissin

Wenn Sie auf Baumkonflikte stoßen, die keinen Sinn ergeben, weil Sie die Datei nicht bearbeitet/gelöscht/in die Nähe gebracht haben, besteht auch eine gute Chance, dass der Befehl merge einen Fehler enthält.

Was passieren kann, ist, dass Sie zuvor bereits einige der Änderungen zusammengeführt haben, die Sie in Ihre aktuelle Zusammenführung einbeziehen. In trunk hat beispielsweise jemand eine Datei bearbeitet und später umbenannt. Wenn Sie bei Ihrer ersten Zusammenführung die Bearbeitung und bei einer zweiten Zusammenführung sowohl die Bearbeitung als auch die Umbenennung (im Wesentlichen ein Entfernen) einschließen, entsteht auch ein Baumkonflikt. Der Grund dafür ist, dass die zuvor zusammengeführte Bearbeitung dann als Ihre eigene angezeigt wird und das Entfernen daher nicht automatisch durchgeführt wird.

Dies kann zumindest in 1.4-Repositories vorkommen. Ich bin mir nicht sicher, ob das in 1.5 eingeführte Mergetracking hier hilft.

4
Ticcie

Ich hatte ein ähnliches Problem. Das einzige, was für mich wirklich funktionierte, war das Löschen der in Konflikt stehenden Unterverzeichnisse mit:

svn delete --force ./SUB_DIR_NAME

Kopieren Sie sie dann erneut aus einem anderen Stammverzeichnis in der Arbeitskopie, in der sie enthalten sind:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Dann mach

svn cleanup

und

svn add *

Beim letzten erhalten Sie möglicherweise Warnungen, aber ignorieren Sie sie einfach und schließlich

svn ci .
1
MFH

Ich bin auch heute auf dieses Problem gestoßen, obwohl mein spezielles Problem wahrscheinlich nicht mit Ihrem zusammenhängt. Nachdem ich die Liste der Dateien überprüft hatte, stellte ich fest, was ich getan hatte - ich hatte vorübergehend eine Datei in einer Baugruppe einer anderen Baugruppe verwendet. Ich habe viele Änderungen daran vorgenommen und wollte den SVN-Verlauf nicht verwaisen. Daher hatte ich in meinem Zweig die Datei aus dem Ordner der anderen Versammlung verschoben. Dies wird von SVN nicht verfolgt. Es sieht also so aus, als würde die Datei gelöscht und dann erneut hinzugefügt. Dies führt letztendlich zu einem Baumkonflikt.

Ich habe das Problem behoben, indem ich die Datei zurück verschoben, festgeschrieben und dann meinen Zweig zusammengeführt habe. Danach habe ich die Datei zurück verschoben. :) Das schien den Trick zu tun.

1
Dave

Ich hatte das gleiche Problem und löste es, indem ich die Zusammenführung mit diese Anweisungen erneut durchführte. Grundsätzlich wird die "2-URL-Zusammenführung" von SVN verwendet, um trunk auf den aktuellen Status Ihres Zweigs zu aktualisieren, ohne sich so sehr um Verlauf und Baumkonflikte zu kümmern. Ich konnte 114 Baumkonflikte nicht manuell beheben.

Ich bin mir nicht sicher, ob es die Geschichte so gut bewahrt, wie man es möchte, aber es hat sich in meinem Fall gelohnt.

0
rescdsk

Ein Szenario, in das ich manchmal stoße:

Angenommen, Sie haben einen Stamm, aus dem Sie einen Freigabezweig erstellt haben. Nach einigen Änderungen am Trunk (insbesondere dem Erstellen eines "some-dir" -Verzeichnisses) erstellen Sie einen Feature/Fix-Zweig, den Sie später auch in den Release-Zweig einbinden möchten (da die Änderungen klein genug waren und das Feature/Fix für das Release wichtig ist). .

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Wenn Sie dann versuchen, den Zweig feature/fix direkt mit dem Zweig release zusammenzuführen, tritt ein Baumkonflikt auf (obwohl das Verzeichnis im Zweig feature/fix noch nicht vorhanden war):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

Sie müssen also explizit die Commits zusammenführen, die auf trunk ausgeführt wurden, bevor Sie einen Feature/Fix-Zweig erstellen, der das Verzeichnis "some-dir" erstellt hat, bevor Sie den Feature/Fix-Zweig zusammenführen.

Ich vergesse das oft, da das in git nicht nötig ist.

0
anre

Seit mindestens drei Monaten bin ich regelmäßig auf Hunderte von Baumkonflikten gestoßen, als ich versuchte, einen Zweig wieder in den Stamm zusammenzuführen (mit TortoiseSVN 1.11 ). Ob neu gegründet oder nicht, übrigens. Ich benutze TortoiseSVN seit Version 1 im Jahr 2004 und habe die ganze Zeit über Zweige reintegriert. Etwas muss wohl kürzlich passiert sein?

Also habe ich heute dieses einfache Experiment durchgeführt und festgestellt, was diese verrückten Konflikte verursacht hat:

  1. Ich gabelte den Kofferraum ab @ 393;
  2. Ich habe Dutzende von Dateien nach dem Zufallsprinzip geändert und neue erstellt.
  3. Ich habe zugesagt. Now @ 395 (ein Kollege hat sich bei 394 verabschiedet, um seine eigenen Arbeiten auszuführen).
  4. Dann habe ich versucht, den Zweig wieder in den Kofferraum zu integrieren. Folgen Sie der Empfehlung von TortoiseSVN im Assistenten: "Um alle Revisionen zusammenzuführen (wieder zu integrieren), lassen Sie dieses Feld leer." Um dies zu erreichen, habe ich mit der rechten Maustaste auf den Trunk-Ordner geklickt und "TortoiseSVN> Merge, from/path/to/branch" gewählt, und ich habe den Drehzahlbereich leer gelassen als auf dem Dialog beraten.

Diskussion: (siehe Anhang)

alle Überarbeitungen ... von was? Wenig wusste ich dass der Client sich dabei auf " alle Revisionen des Ziels! (trunk)" bezogen haben muss Bei der Wiedereingliederung dieses Zweigs sah ich die Erwähnung "Revisionen 1-HEAD zusammenführen"! OH MEIN GOTT. Armer Teufel, du fällst hier in den Tod. Dieser Zweig wurde bei 393 geboren, können Sie nicht die Geburtsurkunde lesen, um Gottes willen? this is why so many conflicts occurred: SVN-cli is going on a foolish spree from revision 1

Auflösung:

  1. Geben Sie im Gegensatz zu den Anweisungen des Assistenten einen Bereich an, der ALLE Revisionen von ... dem Leben der Branche abdeckt! daher 394-HEAD ;
  2. führen Sie nun den Zusammenführungstest erneut aus und holen Sie sich eine Zigarre. ( see second attachment ).

Moral: Ich kann nicht verstehen, warum sie diesen Fehler immer noch nicht behoben haben, weil es einer ist, tut mir leid. Ich sollte mir die Zeit nehmen, dies mit ihnen zu melden.

0
Fabien Haddadi