Warum bekomme ich Baumkonflikte in Subversion?

Question

Ich hatte einen Feature-Zweig meines Stammes und führte regelmäßig Änderungen aus meinem Stamm in meinen Zweig ein und alles funktionierte einwandfrei. Heute wollte ich den Zweig wieder mit dem Stamm zusammenführen, und alle Dateien, die nach der Erstellung meines Zweigs zu meinem Stamm 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.

Answer 1

Dies kann dadurch verursacht werden, dass nicht überall dieselbe Client-Version verwendet wird.

Die Verwendung eines Clients der Version 1.5 und eines Clients der Version 1.6 für dasselbe Repository kann diese Art von Problem verursachen. (Ich war gerade selbst betroffen.)

Answer 2

Bis heute, denn seit mindestens 3 Monaten stieß ich regelmäßig auf Hunderte von Baumkonflikten, wenn ich versuchte, einen Zweig wieder in den Stamm zu integrieren (mit TortoiseSVN 1.11 ). Ob umbasiert oder nicht, übrigens. Ich benutze TortoiseSVN seit der Version 1, damals 2004, und ich habe ständig Zweige neu integriert. Irgendetwas muss in letzter Zeit passiert sein, nehme ich an?

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

1. Ich habe den Kofferraum bei 393 abgezweigt;
2. Ich habe wahllos Dutzende von Dateien geändert und auch neue erstellt;
3. Ich habe mich verpflichtet. Jetzt @395 (ein Kollege hat sich bei 394 abgezweigt, um seine eigenen Sachen zu machen).
4. Dann habe ich versucht, den Zweig wieder in den Stamm zu integrieren, nur zum Test; Ich folgte der Empfehlung von TortoiseSVN im Assistenten: "Um alle Revisionen zusammenzuführen (reintegrieren), lassen Sie das Feld leer". Um dies zu erreichen, klickte ich mit der rechten Maustaste auf den Stammordner und wählte "TortoiseSVN > Zusammenführen, von /pfad/zu/zweig" und ich den Drehzahlbereich leer gelassen , wie im Dialog empfohlen.

Diskussion: (siehe Anhang)

alle Überarbeitungen ... von was? Ich wusste nicht, dass dass sich der Kunde wohl auf " alle Überarbeitungen des Ziels! (trunk)", da ich bei der Reintegration dieses Zweiges den Hinweis "Merging revisions 1-HEAD" sah! OMG. Armer Teufel, du fällst hier in deinen Tod. Dieser Zweig wurde @393 geboren, kannst du nicht seine Geburtsurkunde lesen, um Gottes Willen?

Auflösung:

1. Im Gegensatz zu dem, was der Assistent rät, geben Sie einen Bereich an, der ALLE Revisionen des Lebens des Zweigs abdeckt! daher, 394-KOPF ;
2. Führen Sie jetzt den Zusammenführungstest noch einmal durch und holen Sie sich eine Zigarre. ( ).

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

Answer 3

Wenn Sie auf Baumkonflikte stoßen, die keinen Sinn ergeben, weil Sie die Datei nicht bearbeitet/gelöscht haben oder in die Nähe der Datei gekommen sind, besteht eine gute Chance, dass ein Fehler im Zusammenführungsbefehl vorliegt.

Es kann vorkommen, dass Sie eine Reihe der Änderungen, die Sie in die aktuelle Zusammenführung aufnehmen, bereits zuvor zusammengeführt haben. Zum Beispiel hat jemand im Stamm eine Datei bearbeitet und sie dann später umbenannt. Wenn Sie in Ihrer ersten Zusammenführung die Bearbeitung einbeziehen und dann in einer zweiten Zusammenführung sowohl die Bearbeitung als auch die Umbenennung einbeziehen (im Wesentlichen ein Entfernen), führt dies ebenfalls zu einem Baumkonflikt. Der Grund dafür ist, dass die zuvor zusammengeführte Bearbeitung dann als Ihre eigene erscheint und somit das Entfernen nicht automatisch durchgeführt wird.

Dies kann zumindest bei 1.4 Repositories auftreten, ich bin mir nicht sicher, ob das in 1.5 eingeführte Mergetracking hier hilft.

Answer 4

Ich bin heute auch auf dieses Problem gestoßen, obwohl mein Problem wahrscheinlich nicht mit Ihrem zusammenhängt. Nachdem ich mir die Liste der Dateien angesehen hatte, wurde mir klar, was ich getan hatte - ich hatte vorübergehend eine Datei in einer Baugruppe aus einer anderen Baugruppe verwendet. Ich hatte viele Änderungen daran vorgenommen und wollte die SVN-Historie nicht verwaisen lassen, also hatte ich die Datei in meinem Zweig aus dem Ordner der anderen Baugruppe verschoben. Dies wird von SVN nicht verfolgt, so dass es so aussieht, als ob die Datei gelöscht und dann wieder hinzugefügt wurde. Dies führt zu einem Baumkonflikt.

Ich habe das Problem gelöst, indem ich die Datei zurückgeschoben, bestätigt und dann meinen Zweig zusammenführen. Danach habe ich die Datei wieder zurückgeschoben :) Das schien den Zweck zu erfüllen.

Answer 5

Ich hatte ein ähnliches Problem. Das einzige, was bei mir tatsächlich funktionierte, war, die konfliktbehafteten Unterverzeichnisse mit zu löschen:

svn delete --force ./SUB_DIR_NAME

Kopieren Sie sie dann erneut aus einem anderen Root-Verzeichnis in die Arbeitskopie, die sie mit enthält:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Dann tun Sie

svn cleanup

y

svn add *

Möglicherweise erhalten Sie bei der letzten Option eine Warnung, aber ignorieren Sie sie einfach und

svn ci .