Alle paar Wochen laufe ich in die selbe Falle, beim Refactoring eins kompletten Stangs von Dateien die in einem svn Repository liegen, endet es in einem Tree Conflict der unerwartet ist, wenn man sich die Definition eines Tree Conflicts in der svn Dokumentation ansieht:
But what happens if your collaborators move or delete a file that you are still working on? Maybe there was a miscommunication, and one person thinks the file should be deleted, while another person still wants to commit changes to the file. Or maybe your collaborators did some refactoring, renaming files and moving around directories in the process. If you were still working on these files, those modifications may need to be applied to the files at their new location. Such conflicts manifest themselves at the directory tree structure level rather than at the file content level, and are known as tree conflicts.
Für mich als unbedraften Benutzer liest sich das erstmal so, als würde ich generell nur einen Tree Conflict bekommen können, wenn es mehrere Commiter auf einem Repository, bzw. um genau zu sein einem Teilstrang eines Repositories gibt. Dem ist leider nicht so.
Mir zum Beispiel passiert ein Tree Conflict regelmäßig beim Löschen von Verzeichnissen an denen ich nur selber arbeite und die Ursache in diesem Fall sind „mixed-revision working copies“. „mixed-revision working copies“ sind an sich eine feine Sache, da man anhand dessen in der Lage ist, jedes File und jedes Verzeichnis seines Checkouts einzeln upzudaten, wenn man es braucht. Und da ich das gelegentlich brauche, denke ich mal ich stehe da nicht alleine :-).
Bezüglich des Problems gibt es einen sehr interessanten Thread in der svn Developer Mailingliste, den ich zwar nicht in Gänze wiedergeben will, dessen Quintessenz aber lautet: Will ich einen Verzeichins löschen, so ist es Best Practice, lieber einmal zu viel als einmal zu wenig den Strang auf dem man gerade etwas löschen oder verschieben will upzudaten, damit man für diesen Strang eben nicht eine „mixed-revision working copy“ hat, sondern alle Verzeichnisse auf einer Revision sind.
Und falls es zur Vertiefung etwas Leküre fürs Regal sein soll, empfehle ich das folgende Buch: Versionskontrolle mit Subversion