Warum bekomme ich in Subversion Baumkonflikte?

Ich hatte einen Feature-Zweig in meinem Stamm und führte regelmäßig Änderungen von meinem Stamm in meinen Zweig ein, und alles funktionierte einwandfrei. Heute habe ich den Zweig wieder in den Trunk zusammengeführt und alle Dateien, die nach dem Erstellen meines Zweigs zu meinem Trunk hinzugefügt wurden, wurden als "Baumkonflikt" gekennzeichnet. Gibt es eine Möglichkeit, dies in Zukunft zu vermeiden?

Ich glaube nicht, dass diese richtig gekennzeichnet werden.

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

Zusammenfassend können Sie Folgendes verwenden , um den Baumkonflikt zu lösen, der Ihr Arbeitsverzeichnis mit dem SVN-Client 1.6.x festlegt:

svn resolve --accept working -R .

Wo .ist das Verzeichnis in Konflikt.

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

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

Wenn Sie in TortoiseSVN mit der rechten Maustaste "Gelöst" auswählen, wird dieses Problem tatsächlich behoben.

Subversion 1.6 hat Baumkonflikte hinzugefügt, um Konflikte auf Verzeichnisebene abzudecken. Ein gutes Beispiel wäre, wenn Sie eine Datei lokal löschen und ein Update versucht, eine Textänderung in dieser Datei vorzunehmen. Eine andere Möglichkeit ist, wenn Sie eine Subversion haben. Benennen Sie eine Datei um, die Sie bearbeiten, da dies eine Aktion zum Hinzufügen / Löschen ist.

Der Subversion-Blog von CollabNet enthält einen großartigen Artikel über Baumkonflikte .

Nach meiner Erfahrung 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! Wieder kann ich es kaum erwarten, zu wechseln ...

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

Beispiel:

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

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

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

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 erstellt.

Wenn Sie Ihren Zweig wieder in den Trunk zusammenführen, versucht SVN erneut, dasselbe zu tun: Es wird angezeigt, dass eine Datei in Ihrem Zweig erstellt wurde, und es wird versucht, sie in Ihrem Trunk beim Zusammenführungs-Commit zu erstellen, aber sie ist bereits vorhanden! Dies führt zu einem Baumkonflikt.

Der Weg, dies zu vermeiden, besteht in einer speziellen Zusammenführung, einer Wiedereingliederung . Dies können Sie mit dem --reintegrateSchalter erreichen.

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

Wenn Sie Ihren Zweig wieder mit dem Stamm zusammenführen, ist die zugrunde liegende Mathematik jedoch ganz anders. Ihr Feature-Zweig ist jetzt eine Mischung aus doppelten Trunk-Änderungen und Änderungen des privaten Zweigs. Es gibt also keinen einfachen zusammenhängenden Bereich von Revisionen, über den kopiert werden muss. Wenn Sie die Option --reintegrate angeben, bitten Sie Subversion, nur die Änderungen, die für Ihren Zweig eindeutig sind, sorgfältig zu replizieren. (Und tatsächlich geschieht dies, indem der neueste Stammbaum mit dem neuesten Zweigbaum verglichen wird: Der resultierende Unterschied besteht genau darin, dass sich Ihr Zweig ändert!)

Nach der Wiedereingliederung eines Zweigs ist es sehr ratsam, ihn zu entfernen. Andernfalls treten immer dann Baumkonflikte auf, wenn Sie in die andere Richtung verschmelzen: vom Stamm zu Ihrem Zweig. (Aus genau dem gleichen Grund wie zuvor beschrieben.)

Es gibt auch einen Weg, dies zu umgehen, aber ich habe es nie versucht. Sie können es in diesem Beitrag lesen: Reintegration des Subversion-Zweigs in Version 1.6

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

Die Verwendung eines Clients der Version 1.5 und eines Clients der Version 1.6 für dasselbe Repository kann zu solchen Problemen führen. (Ich wurde gerade selbst gebissen.)

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 zum Zusammenführen einen Fehler aufweist.

Was passieren kann, ist, dass Sie zuvor bereits eine Reihe von Änderungen zusammengeführt haben, die Sie in Ihre aktuelle Zusammenführung einbeziehen. Im 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 eine Entfernung) einschließen, erhalten Sie auch einen 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 bei 1.4-Repositorys auftreten. Ich bin mir nicht sicher, ob das in 1.5 eingeführte Mergetracking hier hilft.

Bis heute, seit mindestens drei Monaten, bin ich regelmäßig auf Hunderte von Baumkonflikten gestoßen, als ich versucht habe, einen Zweig wieder in den Stamm zu integrieren (mit TortoiseSVN 1.11 ). Ob neu basiert oder nicht, übrigens. Ich benutze TortoiseSVN seit Version 1 im Jahr 2004 und habe die Zweige immer wieder neu integriert. Muss wohl kürzlich etwas passiert sein?

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

1. Ich gabelte den Kofferraum @ 393 ab;
2. Ich habe Dutzende von Dateien zufällig geändert und neue erstellt.
3. Ich habe mich verpflichtet. Jetzt @ 395 (ein Kollege gab bei 394 ab, um seine eigenen Sachen zu spielen).
4. Dann habe ich versucht, den Zweig wieder in den Stamm zu integrieren, nur testen; Befolgen Sie die Empfehlung von TortoiseSVN im Assistenten: "Um alle Revisionen zusammenzuführen (erneut zu integrieren), lassen Sie dieses Feld leer." Um dies zu erreichen, klickte ich mit der rechten Maustaste auf den Trunk-Ordner und wählte "TortoiseSVN> Merge, from / path / to / branch". Ich ließ den Drehzahlbereich leer , wie im Dialogfeld empfohlen.

Diskussion: (siehe Anhang)

alle Revisionen ... von was? Ich wusste nicht, dass sich der Client auf " alle Revisionen des Ziels! (Trunk)" bezogen haben muss, da ich bei der Wiedereingliederung dieses Zweigs die Erwähnung "Revisionen 1-HEAD zusammenführen" sah! OH MEIN GOTT. Armer Teufel, du fällst hier in den Tod. Dieser Zweig wurde um 393 geboren. Kannst du nicht die Geburtsurkunde lesen, um Gottes willen?

Auflösung:

1. Geben Sie im Gegensatz zu den Empfehlungen des Assistenten einen Bereich an, der ALLE Revisionen des Lebens der Branche abdeckt! daher 394-HEAD ;
2. Führen Sie nun diesen Zusammenführungstest erneut aus und holen Sie sich eine Zigarre. ( ).

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.

Ich bin heute auch auf dieses Problem gestoßen, obwohl mein spezielles Problem wahrscheinlich nicht mit Ihrem zusammenhängt. Nachdem ich die Liste der Dateien überprüft hatte, wurde mir klar, 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 Assembly 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 zu einem Baumkonflikt.

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

Ich hatte ein ähnliches Problem. Das einzige, was für mich tatsächlich funktioniert hat, 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 *

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

svn ci .

Ich hatte das gleiche Problem und löste es, indem ich die Zusammenführung mithilfe dieser Anweisungen erneut durchführte . Grundsätzlich wird die "2-URL-Zusammenführung" von SVN verwendet, um trunkauf den aktuellen Status Ihres Zweigs zu aktualisieren , ohne sich so sehr um Verlaufs- und Baumkonflikte zu kümmern. Hat mich davor bewahrt, 114 Baumkonflikte manuell zu beheben.

Ich bin mir nicht sicher, ob es die Geschichte so gut bewahrt, wie man es gerne hätte, aber es hat sich in meinem Fall gelohnt.

Ein Szenario, auf das ich manchmal stoße:

Angenommen, Sie haben einen Trunk, aus dem Sie einen Release-Zweig erstellt haben. Nach einigen Änderungen am Trunk (insbesondere beim Erstellen des Verzeichnisses "some-dir") erstellen Sie einen Feature- / Fix-Zweig, den Sie später auch in den Release-Zweig einfügen 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 Feature / Fix-Zweig direkt mit dem Release-Zweig zusammenzuführen, tritt ein Baumkonflikt auf (obwohl das Verzeichnis im Feature / Fix-Zweig 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 die Commits, die auf dem Trunk durchgeführt wurden, explizit zusammenführen, 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.