When I said "It seems to me that a generic cache is strongly preferably from a
design point of view," how "generic" do we need? I think I meant one that is
extensible while keeping the format of the initial implementation, and
preferably extensible in a back-and-forward-compatible manner. It doesn't, for
instance, need to be able to cache properties that our libraries don't know
about - that would be fairly pointless.
Greg Hudson wrote:
>
> 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.
I'm not sure exactly what you mean by these two.
(1) In the current (branch) code, the field in the "entries" file declares the
presence (explicitly) or absence (implicitly) of each of the three properties.
It is "hard-coded" in that the reader needs to know what the writer was thinking.
I think by (2) you perhaps were thinking of the scheme I mentioned in which a
list of present properties and a list of absent properties are both given.
cached-props-present = "svn:special"
cached-props-absent = "svn:needs-lock svn:externals"
That's not a "hard-coded" scheme because the reader doesn't have to know
anything about which properties were put there, it just looks to see if the
property it wants is in either of the lists. Different writers (different
versions of client software) can put different lists of property names into
this cache, and all readers will understand it without knowing who wrote it.
This representation is semantically equivalent to the alternatives I gave such as:
props-presence-cache = "svn:needs-lock=0 svn:special=1 svn:externals=0"
> 3. Declare once per entries file which properties we are caching the
> presence of, and later declare which of those is present.
In this scheme, the per-file field can use a compact bit-sequence to represent
which of the properties are present and which absent, e.g. "010" if there are
three properties being considered.
> 4. Declare the presence of all properties.
By this, I assume you mean: for each item, list the names of all the properties
(presumably only "svn:" properties) that the item has. Anything property whose
name is not in the list is known to be absent. This is more verbose (a longer
string) than (3).
This would make the "has-props" boolean redundant by replacing it with more
information, so it could be called "props". Examples:
props = ""
props = "svn:special"
props = "svn:ignore svn:externals"
This field might as well be required. Calling it a "cache" would be a bit
undeserved as (if present) it is required to always be complete and up to date.
5. Here's a simplification of (3). Since the Subversion client libraries know
which "svn:" properties have any meaning in the current version, we don't need
such a generic cache, and the list of properties can be fixed. Define (as part
of the specification of the WC format) that the sequence of properties is
svn:needs-lock, svn:special, svn:externals
and then have:
props-presence = "010"
for a file which has svn:special but neither of the others.
In future, we can add another property to the end of the list whenever we like.
That will be extensible without a format bump. If a new reader knows about a
fourth property, but the string in the WC only has three entries, then the
fourth property is simply not yet cached. This scheme is more efficient in
space and time than the current field and, I think, the other suggestions.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 29 01:59:56 2005