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

Re: [PATCH] Infrastructure changes for incomplete directory support.

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2006-08-14 21:43:24 CEST

On 8/9/06, Karl Fogel <kfogel@google.com> wrote:
> I haven't committed a code change to Subversion in a while, so posting
> a patch here first. It's pretty self-explanatory. Remember that I'm
> going for infrastructure first, as per this mail:
>
> Also, would people prefer that this work happen on a branch?

Yes, please.

> Note that this change extends .svn/entries format with a new depth
> field. As the log message says, you can turn the change on and off
> and your working copies should be fine. The only way a problem could
> arise is if you were to build with this patch, use the new svn, then
> revert, rebuild with some *other* patch that extends .svn/entries with
> a semantically different field, and then use that svn on the same
> working copies.

From the patch, I concluded you wanted a general depth type. The
current type will be used mainly by libsvn_wc (which doesn't need more
than that), but other parts of the system may benefit from different
depth values: If you need to simulate depth 2 with a series of depth 1
requests, that's sure going to be a lot slower than just 1 depth 2
request. If I were writing an online repository browser like the one
in TSVN or similar to the Windows Explorer, I'd need depth 2 a lot: to
know whether I need to have leaf or subtree nodes (indicated by the
presence/absence of a + before the tree item)...

Well, anyway, it's just something to think about: do we need a general
depth enum or do we need subsystem specific ones?

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 14 21:46:06 2006

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

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