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

Re: Setting sticky depth without grabbing content immediately

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 6 Nov 2013 13:19:17 +0100

On Wed, Nov 6, 2013 at 12:33 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: OBones [mailto:obones_at_free.fr]
>> Sent: dinsdag 5 november 2013 14:06
>> To: Subversion Users
>> Subject: Re: Setting sticky depth without grabbing content immediately
>> Johan Corveleyn wrote:
>> > I think this would be a useful feature. Whether or not someone will
>> > have time to work on it, or someone steps up to write a patch for it,
>> > is another matter. But I'd suggest that you enter this into the issue
>> > tracker in any case. Can you please file an issue for this?
>> Done: http://subversion.tigris.org/issues/show_bug.cgi?id=4445
> Currently the Subversion working only stores one depth value and this depth
> must match what is known about the children.
> If you would update this depth to infinity it would imply that all the
> children are known in the working copy and a further update would not bring
> them in. Fixing this requires keeping a second depth value just to allow
> this UI in one of many Subversion clients, with all kind of backwards
> compatibility concerns.

Perhaps a dumb question...

I don't know whether subversion first sets the depth value in the
metadata, and then processes the update, or vice versa. But if it's
the former, what happens when the update is interrupted after storing
the new depth value but before the children have been "received"? I
suppose this will mean the directory is marked as incomplete or
something like that, so that a subsequent update completes the update
and brings in everything?

Couldn't something similar be used for this use case? I.e. you create
/ prepare an "incomplete working copy" (or where some parts are

Received on 2013-11-06 13:20:30 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.