[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 'svn up -r0' doesn't.

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 04 Jul 2011 12:06:53 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.