On 12 Nov 2005 14:50:18 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> Any time I hear about .svn directories storing Just One More piece of
> information, a bell goes off in my head: "Okay, but is it versioned,
> and if so, how will we make sure it gets outdate/updated correctly?"
The real info is the presence of properties marking parallel root
directories and the project root directory. If you cache that
somewhere for speed or off-line behavior, that's your own business.
Personally, since the whole point of this info is for doing
inter-branch comparisons, I don't see a lot of point in caching it in
the working copy.
> In this case, the property itself is a regular versioned property set
> on a directory. By asking descendant WCs to cache this property in a
> special, non-versioned way, we're essentially implementing inherited
> properties, but cheaply and with uncertain semantics :-).
Let's presume we were going to cache the values in the WC, just for
the sake of generality. I don't see what you mean by "non-versioned"
or "uncertain". The official semantics are that you do a search for
the property up to the root of the revision. If you cache it
client-side, then you've got a cache whose coherency you need to
maintain, but correct caches should never affect the semantics of a
feature.
> But we should consider the edge cases: what happens to the
> working copies when these properties disappear or change?
A WC directory is always based on a particular path in a particular
revision. You scan up that directory's parents in that revision.
There's nothing edge-casey about this.
> How does a
> working copy's cache behave if an "impossible" situation happens in
> the repository such that multiple directories in a path chain have the
> same property set?
There is no "impossible situation" involved here that I can see.
> Also, why are we caching them in the WC at all? Jim's original
> proposal involved contacting the server and having it walk upward from
> certain paths until it found certain properties. Marc's proposal
> changes the properties and their meanings somewhat, *and* adds WC
> caching to the picture. Couldn't we do just the former, but not the
> latter?
Yep. I think the WC caching, without some kind of general framework
for invalidating such caches, is a tar baby for this particular
feature. But if we solve it for log templates, then the parallel tree
abbreviations would benefit.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 13 00:04:30 2005