Ab und an werden Sie einen Konflikt erhalten, wenn Sie Ihre Arbeitskopie aktualisieren oder zu einer anderen URL wechseln. Es gibt zwei Arten von Konflikten:
Ein Dateikonflikt entsteht, wenn zwei (oder mehr) Entwickler dieselben Zeilen einer Datei geändert haben.
Ein Baumkonflikt entsteht, wenn ein Entwickler eine Datei oder einen Ordner umbenannt, verschoben oder gelöscht hat, den ein anderer Entwickler ebenfalls umbenannt, verschoben, gelöscht oder bearbeitet hat.
Ein Konflikt tritt dann auf wenn mehrere Personen die gleichen Zeilen in einer Datei verändert haben. Da Subversion nichts über Ihr Projekt weiß, überlässt es in solchen Fällen Ihnen, den Konflikt aufzulösen. Wann immer ein Konflikt auftritt, können Sie die entsprechende Datei öffnen und nach Zeilen suchen welche mit <<<<<<< beginnen. Die Zeile in Konflikt ist folgendermaßen markiert:
<<<<<<< Dateiname
Ihre Änderungen
=======
Code aus dem Projektarchiv
>>>>>>> Revision
Außerdem werden für jede Datei in Konflikt drei weitere Dateien erstellt:
Dies ist die Datei, so wie Sie war bevor Sie Ihre Arbeitskopie aktualisierten. Das heißt es ist Ihre eigene Originaldatei, inklusive der Änderungen welche Sie selbst vorgenommen haben.
Dies ist die Datei wie Sie ursprünglich war, ohne jegliche Änderungen, auch ohne den Änderungen welche Sie selbst an der Datei vorgenommen haben.
Dies ist die Datei, wie sie im Projektarchiv gerade aktuell ist, d.h. diese Datei hat die Änderungen von den anderen Mitarbeitern bereits integriert, jedoch noch nicht die Ihren.
Sie können nun entweder einen Konflikteditor benutzen, den Sie durch den Befehl → aufrufen können oder Sie können die Datei mit einem normalen Texteditor ändern und den Konflikt auf diese Weise auflösen.
Anschließend müssen Sie Subversion noch mitteilen, dass Sie den Konflikt aufgelöst haben. Dies geschieht mit dem Befehl → . Bitte beachten Sie dass dieser Befehl nicht den Konflikt selbst löst, sondern nur Subversion mitteilt dass Sie selbst den Konflikt bereits gelöst haben. Der Befehl macht nichts weiter als die drei zusätzlich erstellten Dateien filename.ext.mine und filename.ext.r*zu löschen, damit sie Ihre Änderungen in das Projektarchiv übertragen können.
Falls ein Konflikt zwischen Binärdaten besteht, versucht Subversion nicht, die Daten selbst zusammenzuführen. Die lokale Datei bleibt unverändert (exakt so, wie sie Ihrer letzten Änderung entspricht) und Sie erhalten Dateiname.ext.r* Dateien. Wenn Sie Ihre eigenen Änderungen verwerfen wollen, tun Sie das mit dem Befehl. Wenn Sie Ihre Version beibehalten und die Version im Projektarchiv überschreiben wollen, verwenden Sie den Befehl und übertragen anschließend die Daten ins Projektarchiv
Sie können den Befehl für mehrere Dateien verwenden, indem Sie den übergeordneten Ordner markieren und → aus dem Kontextmenü wählen. Dies öffnet einen Auswahldialog, in dem alle konfliktbehafteten Dateien aufgelistet sind. Wählen Sie die Dateien, die sie als aufgelöst markieren wollen.
Ein Baumkonflikt entsteht, wenn ein Entwickler eine Datei oder einen Ordner umbenannt, verschoben oder gelöscht hat, den ein anderer Entwickler ebenfalls umbenannt, verschoben, gelöscht oder bearbeitet hat. Es gibt verschiedene Ursachen für Baumkonflikte und alle erfordern unterschiedliche Vorgehensweisen, um den Konflikt aufzulösen.
Wenn eine Datei in Subversion lokal gelöscht wird, wird sie auch aus dem lokalen Dateisystem gelöscht. Das bedeutet, dass kein überlagertes Symbol angezeigt werden kann, wenn sie Teil eines Baumkonfliktes ist und dass Sie den Konflikt nicht mit Hilfe eines Rechtsklicks auflösen können. Verwenden Sie stattdessen den Auf Änderungen prüfen Dialog, um den Konflikt bearbeiten zu können.
TortoiseSVN kann dabei helfen, Änderungen zusammenzuführen, aber es kann zusätzliche Arbeit erforderlich sein, um die Konflikte aufzulösen. Bedenken Sie, dass nach eine Aktualisierung die BASE der Arbeitskopie dem Inhalt des Projektarchivs entspricht. Wenn Sie eine Änderung nach dem Aktualisieren rückgängig machen, wird das Objekt in den Status des Projektarchivs zurückversetzt und nicht in den Zustand in dem sie begonnen haben, ihre eigenen Änderungen durchzuführen.
Entwickler A verändert die Datei Foo.c und überträgt die Änderung ins Projektarchiv.
Entwickler B benennt gleichzeitig die Datei Foo.c in seiner Arbeitskopie in Bar.c um oder löscht Foo.c bzw. den Elternordner.
Eine Aktualisierung der Arbeitskopie von Entwickler B resultiert in einem Baumkonflikt:
Die Datei Foo.c wurde aus der Arbeitskopie gelöscht, ist aber gleichzeitig als Baumkonflikt markiert.
Wenn ein Konflikt nicht von einem Löschen, sondern von einem Umbenennen herrührt, ist die DateiBar.c als hinzugefügt markiert, enthält aber nicht die Änderungen von Entwickler A.
Entwickler B muss sich nun entscheiden, ob er die Änderungen von Entwickler A übernehmen möchte. Im Fall des Umbenennens kann er die Änderungen an Foo.c in Bar.c zusammenführen. Für einfache Löschungen kann er das Objekt mit den Änderungen von Entwickler A beibehalten und das Löschen verwerfen. Oder er kann, indem er den Konflikt ohne weitere Aktionen als aufgelöst markiert, die Änderungen von Entwickler A verwerfen.
Der Dialog zum Auflösen von Konflikten bietet Ihnen an, die Änderungen zusammenzuführen, wenn er das Original der umbenannten Datei Bar.c finden kann. Abhängig davon, von wo aus die Aktualisierung angestoßen wurde, kann das nicht möglich sein.
Entwickler A benennt die Datei Foo.c in Bar.c um und überträgt die Änderung ins Projektarchiv.
Entwickler B verschiebt die Datei Foo.c in seiner Arbeitskopie.
Oder im Fall eines verschobenen Ordners...
Entwickler A benennt den Elternordner FooOrdner in BarFolder um und überträgt die Änderung ins Projektarchiv.
Entwickler B verschiebt die Datei Foo.c in seiner Arbeitskopie.
Eine Aktualisierung der Arbeitskopie von Entwickler B führt zu einem Baumkonflikt. Für einen einfachen Dateikonflikt:
Die Datei Bar.c wird als normale Datei zur Arbeitskopie hinzugefügt.
Die Datei Foo.c ist als hinzugefügt mit Historie markiert und hat einen Baumkonflikt.
Für einen Ordnerkonflikt:
BarOrdner wird als normaler Ordner zur Arbeitskopie hinzugefügt.
Der Ordner FooOrdner ist als hinzugefügt mit Historie markiert und hat einen Baumkonflikt.
Die Datei Foo.c ist als verändert markiert.
Entwickler B muss nun entscheiden, ob er die Reorganisation durch Entwickler A übernehmen will und seine Änderungen in der entsprechenden Datei in der neuen Struktur zusammenführt oder ob er einfach die Änderungen von A rückgängig macht und die lokale Datei beibehält.
Um seine lokalen Änderungen mit der Umstrukturierung zusammenzuführen, muss Entwickler B zunächst herausfinden wie die konfliktbehaftete Datei Foo.c im Projektarchiv umbenannt wurde. Dies kann mit Hilfe des Log-Dialogs geschehen. Die Änderungen müssen manuell zusammengeführt werden, da es derzeit keine Möglichkeit gibt, dies zu automatisieren oder zu vereinfachen. Sobald die Änderungen übernommen wurden, ist der konfliktbehaftete Pfad überflüssig und kann gelöscht werden. Verwenden Sie dazu die Entfernen Schaltfläche im Konflikteditor. Damit wird dieser Konflikt als aufgelöst markiert.
Falls Entwickler B beschließt, dass die Änderungen von A falsch waren, muss er Beibehalten im Konflikteditor wählen. Dadurch wird der Konflikt als aufgeöst markiert, aber die Änderungen von Entwickler A müssen manuell zurückgenommen werden. Der Log-Dialog hilft Ihnen wieder dabei festzustellen, was verschoben wurde.
Entwickler A benennt die Datei Foo.c in Bar.c um und überträgt die Änderung ins Projektarchiv.
Entwickler B benenntFoo.c in Bix.c um.
Eine Aktualisierung der Arbeitskopie von Entwickler B resultiert in einem Baumkonflikt:
Die Datei Bix.c ist als hinzugefügt mit Historie markiert.
Die Datei Bar.c ist als normal markiert.
Die Datei Foo.c ist als gelöscht markiert und hat einen Baumkonflikt.
Um diesen Konflikt aufzulösen, muss Entwickler B zunächst herausfinden wie die konfliktbehaftete Datei Foo.c im Projektarchiv umbenannt wurde. Dies kann mit Hilfe des Log-Dialogs geschehen.
Danach muss sich Entwickler B entscheiden, welchen neuen Dateinamen von Foo.c er übernehmen möchte, den eigenen oder den von Entwickler A vergebenen Namen.
Nachdem Entwickler B den Konflikt manuell aufgelöst hat, muss der Baumkonflikt mit der Schaltfläche im Konflikteditor als aufgelöst markiert werden.
Entwickler A verändert im Stamm die Datei Foo.c um und überträgt die Änderung ins Projektarchiv.
Entwickler B, der auf einem Zweig arbeitet, benennt Foo.c in Bar.c um und überträgt die Änderung ins Projektarchiv.
Das Zusammenführen der Änderungen von Entwickler A im Stamm mit der Arbeitskopie von Entwickler B führt zu einem Baumkonflikt:
Die Datei Bar.c befindet sich bereits mit dem Status normal in der Arbeitskopie.
Die Datei Foo.c ist als fehlend markiert und hat einen Baumkonflikt.
Um diesen Konflikt aufzulösen, muss Entwickler B den Dateikonflikt im Konflikteditor als aufgelöst markieren, wodurch er aus der Konfliktliste entfernt wird. Danach muss er entscheiden, ob er die fehlende Datei Foo.c aus dem Projektarchiv in die Arbeitskopie kopiert, die Änderungen von Entwickler A an Foo.c in die umbenannte Datei Bar.c überträgt oder die Änderungen ignoriert, indem er den Konflikt als aufgelöst markiert und nichts weiter unternimmt.
Beachten Sie, dass wenn Sie die fehlende Datei aus dem Projektarchiv kopieren und danach den Konflikt als aufgelöst markieren, ihre Kopie wieder entfernt wird. Sie müssen den Konflikt erst auflösen und danach die Datei kopieren.
Entwickler A benennt im Stamm die Datei Foo.c in Bar.c um und überträgt die Änderung ins Projektarchiv.
Entwickler B, der auf einem Zweig arbeitet, modifiziert Foo.c und überträgt die Änderung ins Projektarchiv.
Es gibt einen äquivalenten Fall für verschobene Ordner, dieser wird aber in Subversion 1.6 noch nicht erkannt ...
Entwickler A benennt im Stamm den Ordner FooOrdner in BarOrdner um und überträgt die Änderung ins Projektarchiv.
Entwickler B, der auf einem Zweig arbeitet, verändert Foo.c in seiner Arbeitskopie.
Das Zusammenführen der Änderungen von Entwickler A im Stamm mit der Arbeitskopie von Entwickler B führt zu einem Baumkonflikt:
Die Datei Bar.c ist als hinzugefügt markiert.
Die Datei Foo.c ist als verändert markiert und hat einen Baumkonflikt.
Entwickler B muss nun entscheiden, ob er die Reorganisation durch Entwickler A übernehmen will und seine Änderungen in der entsprechenden Datei in der neuen Struktur zusammenführt oder ob er einfach die Änderungen von A rückgängig macht und die lokale Datei beibehält.
Um die lokalen Änderungen mit der Reorganisation zusammenzuführen, muss Entwickler B zunächst herausfinden wie die konfliktbehaftete Datei Foo.c im Projektarchiv umbenannt wurde. Dies kann mit Hilfe des Log-Dialogs für die Quelle des Zusammenführens geschehen. Der Konflikteditor zeigt nur das Log für die Arbeitskopie an, da er nicht wissen kann, welcher Pfad zum Zusammenführen genutzt wurde. Aus diesem Grund müssen Sie das selbst herausfinden. Die Änderungen müssen manuell zusammengeführt werden, da es derzeit keine Möglichkeit gibt, dies zu automatisieren oder zu vereinfachen. Sobald die Änderungen übernommen wurden, ist der konfliktbehaftete Pfad überflüssig und kann gelöscht werden. Verwenden Sie dazu die Entfernen Schaltfläche im Konflikteditor. Damit wird dieser Konflikt als aufgelöst markiert.
Falls Entwickler B beschließt, dass die Änderungen von A falsch waren, muss er Beibehalten im Konflikteditor wählen. Dadurch wird der Konflikt als aufgeöst markiert, aber die Änderungen von Entwickler A müssen manuell zurückgenommen werden. Der Log-Dialog hilft Ihnen wieder dabei festzustellen, was verschoben wurde.
Entwickler A benennt im Stamm die Datei Foo.c in Bar.c um und überträgt die Änderung ins Projektarchiv.
Entwickler B, der auf einem Zweig arbeitet, benennt Foo.c in Bix.c um und überträgt die Änderung ins Projektarchiv.
Das Zusammenführen der Änderungen von Entwickler A im Stamm mit der Arbeitskopie von Entwickler B führt zu einem Baumkonflikt:
Die Datei Bix.c ist als normal (unverändert) markiert.
Die Datei Bar.c ist als hinzugefügt mit Historie markiert.
Die Datei Foo.c ist als fehlend markiert und hat einen Baumkonflikt.
Um diesen Konflikt aufzulösen, muss Entwickler B zunächst herausfinden wie die konfliktbehaftete Datei Foo.c im Projektarchiv umbenannt wurde. Dies kann mit Hilfe des Log-Dialogs für die Quelle des Zusammenführens geschehen. Der Konflikteditor zeigt nur das Log für die Arbeitskopie an, da er nicht wissen kann, welcher Pfad zum Zusammenführen genutzt wurde. Aus diesem Grund müssen Sie das selbst herausfinden.
Danach muss sich Entwickler B entscheiden, welchen neuen Dateinamen von Foo.c er übernehmen möchte, den eigenen oder den von Entwickler A vergebenen Namen.
Nachdem Entwickler B den Konflikt manuell aufgelöst hat, muss der Baumkonflikt mit der Schaltfläche im Konflikteditor als aufgelöst markiert werden.
Es gibt weitere Fälle, die einfach deshalb als Baumkonflikte gekennzeichnet werden, weil der Konflikt einen Ordner anstelle einer Datei betrifft. Wenn Sie z.B. einen Ordner des gleichen Namens sowohl zu trunk als auch zu branch hinzufügen und versuchen, diese Änderungen zusammenzuführen, erhalten Sie einen Baumkonflikt. Wenn Sie den Zielordner behalten wollen, markieren Sie den Konflikt einfach als aufgelöst. Wenn Sie den Quellordner behalten wollen, müssen Sie zunächst im Projektarchiv den Zielordner löschen und das Zusammenführen neu starten. Kompliziertere Situationen müssen Sie manuell auflösen.