Daniel Shahaf <d...@daniel.shahaf.name> writes: > Philip Martin wrote on Mon, Jul 04, 2011 at 10:18:49 +0100: >> Philip Martin <philip.mar...@wandisco.com> writes: >> >> > I really follow what you are doing, what you expect to happen or what >> > did happen. Can you produce a simple recipe? >> >> That should be "I didn't really follow". When I run 'svn up -r0 m' the >> target m doesn't appear to exist (because the earlier update failed?) >> and I get no conflict, just "At revision 0.". > > What I do: > > svn up -r 0 $SUBDIR > > What happens: > > after the update, the whole $SUBDIR/** hierarchy is present > > What I expect to happen: > > after the update, as I understand your earlier emails, > [ `find $SUBDIR | wc -l` -le 2 ] > > > What I did: in the email I wrote 'svn up -r 0 m' (rather than the actual > name of that directory) because the infra repository is not public. On > my shell session, m/f/h/e/ really was m*/f*/h*/e*/.
Still not clear. A simple recipe that didn't rely on infra would be better. $ svn up -r0 m D m Removed external 'm/j/.../e/a' Updated to revision 0. The only NODES row that is "local_relpath LIKE 'trunk/m'" is not-present so the update has removed all the metadata. I see is the 'm/j/.../e' is still present on disk but unversioned. I suppose that's a bug in externals handling, it has not removed the intervening subdirs. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
