On Mon, 28 Nov 2005, Julian Foad wrote:
> Peter N. Lundblad wrote:
> > I'd like to give a short status report on the wc-propcaching branch. The
> > original plan for wc-propcaching is now implemented. And it seems to work
> > pretty well.
> >
> > The following things have changed regarding how properties are stored:
>
> Is this set of changes, and/or the new situation, documented anywhere more
> permanent than here? I'm going to review this as if it's a log message.
>
They are in the log messages:-) But seriously, I want to work on a new
document describing the current working copy format, because it would be
really helpful to have a complete overview somewhere. I want to get this
in first, though.
>
> > - There is no base-props file if there are no properties.
>
> Excellent. Presumably "if there are no _base_ properties", so this file can
> never be present and empty? (An alternative could be "if there are no base or
> working properties".)
>
Yes, this is what I meant. No base-props file if no base-props.
> > - There is no working props file if there are no prop changes.
>
> Excellent. So, this file can be present and empty, iff there were base props
> and they have all been deleted locally?
>
Correct.
> > - Thrre new fields have been added to the entries file:
> > - has-props keeps track of wheter the entry has any (working) props.
>
> So, to check I understand properly, this is a boolean field, present iff:
> (working-props file is present and non-empty)
> || ((working-props file is absent)
> && (base-props file is present (and, by definition, non-empty)))
> ?
Yes. has-props reflects the state of the working props. So your boolean
statement above is what's implemented.
>
> > - cached-props: is a space-separated list of property names.
> > If a property is mentioned here, the working props for this entry has
> > a property of this name. Only svn:needs-lock, svn_special and
> > svn:externals may be present in this field.
>
> And if one of those three properties is not mentioned, does that mean the
> property is not present in the working props? So this caches the presence or
> absence of those three particular properties? (See below.)
>
Exactly.
>
> > - prop-mods: Is true or false (attribute absent) depending on whether
> > this entry has property modifications.
>
> Wouldn't the name "has-prop-mods" be better for a boolean (complementing
> "has-props")? Otherwise its name implies it's a list of modifications.
>
Good idea.
> So, this is present iff the "working props" files is present?
>
Yes, you could say that it caches the presence of that file:-)
> > What we are waiting for now is that Erik wants to require checksums on all
> > files. Since that would require even another WC format bump, we think it
> > is best to do that on wc-propcaching before merging.
>
> That makes me uncomfortable. Maybe it's a small and simple change, but
> it's got nothing to do with prop-caching. Saying that format numbers
> are cheap, and then doing this to avoid another bump, is inconsistent.
Hehe, caught me there:-)
> Is there any other way we could work around this format-number-bumping
> issue? Please could we either keep bumps for released versions, and
> provide developers with an alternative way to get their WCs upgraded and
> working yet end up with a format number "5", or just do a bump for each
> new WC feature? Mixing different features in the same branch could get
> ugly and isn't scaleable.
>
I think the latter alternative is ellegant. The format number doesn't mean
anything outside the WC internals and asking developers to hack their
working copies (or recheck them out) isn't very nice.
Erik, do you agree to move your checksum work outside the wc-propcaching
branch?
>
> We have:
>
> cached-props = "svn:special"
>
> means
>
> svn:needs-lock is absent, svn:special is present, svn:externals is absent.
>
> Note that it means certain properties are absent, that aren't mentioned
> in it, as well as meaning that certain properties are present (that are
> mentioned in it).
>
> The library has built-in knowledge of which three specific properties
> they are.
> Calling the field "cached-props" seems wrong. It implies a generic
> cache, in which the presence or absence of an item should indicate only
> whether that item happens to have been cached. Writing the name of the
> property for one boolean state ("present") but not for the other state
> ("absent") is asymmetric.
>
We are assymetric for boolean attributes, mostly to save space. Naming
absent properties for each entry just for symmetry is silly; let's find
another solutioin here.
[...]
> cached-props-names = "svn:needs-lock svn:special svn:externals"
> cached-props-presence = "0 1 0"
>
Move the first of these at the top-level (or the this-dir entry) and you
have ghudson's suggestion. This might be an alternative.
> 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. From an implementation POV, I rather do this
simpler solution. Maybe we shouldn't bother if people store 1000 props,
then they're deemed anyway. I'll give this some time to think about, but
I may well end up caching the existence of all props.
Thanks for the comments,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 17:11:46 2005