Nachdem ich mich gerade mit einer eben solchen ungewollten nested working copy(es gibt da sicher auch praktische Anwendungfälle einer gewollten nested working copy, z.B. als Alternative zum einbinden von externals) herumgeschlagen habe, stellt sich als erstes die Fage wie komme ich zu einer solchen und vielleicht noch viel wichtiger: Wie werde ich sie wieder los?
Die erste Frage beantwortet sich ganz einfach: Mal kurz einen Moment nicht nachgedacht, das man sich in einer mit svn verwalteten Struktur befindet und schwubs hat man beim manuellen refactorn ein Directory verschoben ohne sich den Kommandos ’svn move‘ zu bedienen. In diesem Moment hat man den Bezug der svn root zu diem Teilstrang aufgelöst. Gleichzeit erkennt der svn-Client aber ganz richtig, das es sich bei dem noch vorhanden Strang um eine svn Struktur handelt. Zack da ist sie, unsere nested working copy, die wir gar nicht wollten.
Wenn wir Glück haben bemerken wir das Missgeschick recht zügig, machen ein revert und machen dann ein svn move und alles ist gut. Wenn wir aber Pech haben, haben wir so viel über den Haufen geworgen, das es ein echtes Stück Arbeit, das alles wieder zurückzudrehen und geordnet nochmals durchzuführen. In diesem Fall hilft es, in den nested working copies die .svn Verzeichnisse zu löschen. Einziger Wermutstropfen: Die History der files geht verloren, was unter Umständen zu verschmerzen ist.
Und weil es mir so gut geholfen hat, die Zeile zum rekursiven Löschen der .svn Directories, das Kommando löscht alle .svn Directories vom aktuellen Pfad abwärts:
rm -rf `find . -type d -name .svn` |
Für eine Empfehlung, wie man dieses Problem elegant lösen kann bin ich natürlich offen und freue mich auf Wortmeldungen.
Und falls es zur Vertiefung etwas Leküre fürs Regal sein soll, empfehle ich das folgende Buch: Versionskontrolle mit Subversion