A colleague new to Subversion has a part of a project spread across a number of sibling directories. He had been making some significant changes and didn't want to “risk” doing a ‘svn update’ on the top level directory, instead manually doing updates on the siblings of the main directory he was working in. These piecemeal updates happened across several days, spanning several revisions.
When we came to make a branch for his work as ‘svn switch’ to it (at his top-level), we found that most of the sibling directories were still linked to their positions in trunk.
I'm guessing that the multiple individual updates ‘pinned’ the siblings to the respective revision of the update as if a a ‘svn switch’ had been done.
Given that where we ended up was a mess of our (well, his) own devising, I'm left wondering what the best recovery would have been? I had to manually ‘svn-switch’ the sibling dirs., sort out the commit, then clear out the whole lot with a fresh checkout (well, I actually set the root depth to “only” followed by “infinity” to reset it).
In general, if you have a hierarchy that may have had some switches (etc.) applied at arbitrary locations within it, is there a way to enforce an update at the top level that undoes the switches (without blowing it all away and re-creating the working copy, as there may be local changes)?
-- [n...@fnx ~]# rm -f .signature [n...@fnx ~]# ls -l .signature ls: .signature: No such file or directory [n...@fnx ~]# exit
