If 'svn up' tries to delete a versioned directory, and the directory contains
unversioned and/or locally-changed files, then an error is thrown back to the
client:
svn: Won't delete locally modified directory 'b'
svn: Left locally modified or unversioned files
Then 'svn up' just stops. But it doesn't have to... the directory *is*
successfully removed from version control: it's no longer in any entries file,
and all that's left behind is an unversioned dir containing some scattered paths
to unversioned files. If the user runs 'svn up' again, the update process
continues and finishes happily.
So: why are we stopping at all?
At least one user has reported this annoyance: their working copies are full of
unversioned objects (.o files, for example), and every time somebody moves a
directory in the tree, people have to run 'svn up' at least twice to complete
the update. Pretty dumb.
What we really want is svn to print some sort of warning about leaving
unversioned files behind, not throw a full-out error. There is no error, just
some information to report. It's just a matter of trapping a very specific
error-code at a precise spot in our code. Should be quite easy to fix.
Major