Johan Corveleyn wrote on Thu, Sep 23, 2010 at 12:40:35 +0200: > [now with better subject line (clicked send too soon on previous > mail), please use this thread iso the other one] > > Hi all, > > I don't know if this is already a known issue/bug (in issue tracker or > mailinglist), but I consider this a bug: >
Which version of svn? Does it reproduce with trunk? (libsvn_wc has been largely rewritten, remember) > 1) Change a directory external definition and commit it (for instance, > let it point to a new release branch). > Is the commit necessary? > 2) svn update > > 3) Interrupt the update (Ctrl-C) while it is processing the "switch" > of the external. I did this after some files of the external were > already Updated. > It's not immediate to reproduce this in a greek tree repository (the update runs too fast)... :-( I suppose I could just use larger files in the test repository, though. Or perhaps compile a conditional-on-filename abort() into svn/notify.c. (but I'm sure there's an easier way... I have a tendency to overlook the simple solutions sometimes) > 4) svn status now shows a lot of files and directories as S > (switched), and some directories missing. Running svn info on the > switched files/dirs shows that they are associated with the correct > (new) location (where the new external definition points to), but they > are still marked as switched. > > Running svn update again fixes the "missing" dirs, but not the > switched nodes. "svn revert" does nothing (which is logical: there are > no local changes). "svn cleanup" does nothing. > Have you tried running 'svn switch $new_url $external_dir'? > The only way I know of to fix this is to delete from disk the entire > subtree that's coming from the external, and svn update again to let > it be pulled in again. > > Does anyone know if this is already known/tracked somewhere? I > couldn't find it in the issue tracker. > > If not, I'll file a new issue (unless someone can convice me that this > is a feature, not a bug :-)). > > Cheers, > -- > Johan
