Jim Blandy <jimb@red-bean.com> writes:
> 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.
Sure -- I was delving into the cache-invalidation strategy, that's
all. (It would be more constructive if I tried to come up with that
strategy myself, but I'd prefer to jut my lip poutily and make Marc do
it.)
> > 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.
The so-called impossible situation is if you have a chain of
directories in which two or more both have the P or T property, e.g.:
/myproj/branches/experimental/skunkworks/mybranch_of_myproj/...
`--- T ---' `-- T ---'
What if both 'experimental' and 'skunkworks' have the T property?
Marc stipulated we'd have a rule saying that should never happen:
> Some error checking can be added to this:
> - When setting the properties, or on "svn cp" for branching/tagging,
> assert that the treeroot is not within another treeroot, and assert
> that the projectroot is not within another projectroot or treeroot
That's fine, however, there will probably still be ways to cause it to
happen. I just wanted to know what the WC caching semantics would be
in that case. We can define it as an error condition and say the
cache is undefined, if we want.
However, I'd guess that for the sake of other properties we might want
to cache, the better solution would to always cache the deepest
property, see below...
> 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.
Definitely! Inherited properties are a panacea for a lot of features:
autoprop configurations, log message templates, this new
find-related-branches-easily idea, svn:ignore propagation. I'm
probably forgetting others.
If we can get this working ("this" being "wc-side caching of certain
properties found in an N-parent of the current directory"), then we
might have a very big win on our hands :-).
I think the valuable insight Marc and you have led us to is that what
we want is the *effect* of inherited properties, not necessarily
inherited properties themselves.
Previous discussions concentrated on ways to get directory D's
property reflected in D's descendents *as a regular property*, and we
ran into all sorts of hairy questions that way. But if we disentangle
the inherited properties from the regular properties, and put the
inherited in their own cache, maybe a lot of those problems go away.
I'm on the verge of proposing a full description of how that cache
could be maintained, but I can tell I need to let it stew for a bit
longer... However, please don't let that stop you (you or Marc or
anyone else, that is) from posting such a description yourself. I
don't think I'd come up with anything better than what you would.
Let's try to avoid adding new files in the .svn area, though :-).
Daniel Berlin is throwing his heart into reducing the file/inode
penalty in there; we don't want to undo this good work. Having the
cache in, say, .svn/entries would be fine, IMHO.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 13 01:43:16 2005