Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> Philip Martin wrote on Mon, Jul 04, 2011 at 10:18:49 +0100:
>> Philip Martin <philip.martin_at_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
Received on 2011-07-04 13:07:35 CEST