Der Heiko war ja schon als Fläming 2000 der Burner, aber das neue Banner ist echt der Hammer(wobei der Gute mir selbstredend immer noch lieber ist wie die Nazispacken, die nebenan in ihrer Garage unter der Reichskriegsflagge gesessen haben):
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
Ich baue an einer WordPress Installation die Comments via XML-RPC Schnittstelle entgegen nimmt, um diese innerhalb der WordPress Admin Oberfläche zu verwalten. Dabei ist mir das Problem untergekommen, das Comments ihre IP und den User-Agent verlieren, bzw. nicht die IP und der User-Agent des orginal kommentierenden Benutzers durchgeschliffen werden können, sondern zwangsläufig die IP und der User-Agent der via XML-RPC zugreifenden Applikation verwandt wird.
Ein wenig Gewühle im WordPress Code bestätigt die Vermutung: IP und User-Agent werden in der wp_new_comment() Funktion hart mit $_SERVER[„REMOTE_ADDR“] und $_SERVER[„HTTP_USER_AGENT“] belegt. Um das Problem zu lösen hab ich den Entwicklern einen kleine Patch zukommen lassen, der diese unflexible Handhabung von IP und User-Agent behebt. Und was soll ich sagen, es sieht ganz danach aus, als würde der Patch in WordPress 3.1 einfließen. Welch Freude für mein kleines Entwicklerherz, da ich dann zumindest ein WordPress Plugin schreiben kann, welches die XML-RPC Schnittstelle dahin gehend erweitert, IP und USER-AGENT bei Bedarf durchzuschleifen.