Re: Status of wc-propcaching branch

On Mon, 2005-11-28 at 16:57 +0100, Peter N. Lundblad wrote:
> > It seems to me that a generic cache is strongly preferably from a design
> > point of view.

> My only concern is that the entries file will grow even bigger, but that
> might be over-pesimistic.

I'm also concerned that listing all existing properties might be
overdoing things. Let me step back and list the options I've seen
presented:

  1. (Current) Declare the presence of three hardcoded properties.

  2. Declare the presence and absence of three hardcoded properties.

  3. Declare once per entries file which properties we are caching the
presence of, and later declare which of those is present.

  4. Declare the presence of all properties.

Any of (2)-(4) would allow us to start caching the presence of
additional properties without a format bump--the information in the
entries file would be enough to determine whether or not we know about
the new property.

(2) has the disadvantage that every entry pays a penalty for every
hardcoded property in the list, even if the working copy has no
properties. Right now that penalty might be small enough to ignore; as
the list grows, it might not.

I like (3), but maybe it's too much code for the benefit.

(4) isn't bad from a total space perspective. Storing each property
name twice instead of once in the .svn area is pretty minor. The main
risk is that a single file with a bunch of custom properties on it would
penalize the processing of any file in the directory. If we're thinking
about storing all properties for a directory in a single file, we're
probably willing to take that risk anyway.

(1) wouldn't be the end of the world. It would be a little clunky if we
want to start caching more props (we'd have to add a new field like
"more-cached-props" instead of modifying the cached-props field). But
I'd advocate choosing between (3) and (4) based on how complex (3) comes
out to be.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 18:18:03 2005