On 12 Nov 2005 17:24:16 -0600, firstname.lastname@example.org <email@example.com> wrote:
> Jim Blandy <firstname.lastname@example.org> 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
I thought you were uncertain about what the visible semantics would
be. I agree that there are interesting questions in the
implementation of a correct cache. But the desired semantics here are
very simple: we have 'svn propget --search-up'. The cache hopefully
makes it fast, and makes it work off-line, but should have no effect
on the meaning of the operation.
> 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.:
> `--- 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
I certainly agree. I want to help people keep track of what they're
trying to do and warn about things that look suspicious, but I'm not
in favor of actually restricting Subversion's behavior in the presence
of these properties. (Of course, if the user actually set some flag
saying "Please prevent me from breaking proper structure" --- like
using -Werror in GCC --- then that would be okay.)
If we simply explain in the documentation how + expansion works, in
terms of searching upwards for directory properties, users can see for
themselves what behavior ill-formed properties will cause.
> 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...
That's what it adds up to.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Nov 13 02:13:19 2005