I'm pretty sure we're all talking about the same thing, but to be
positive: the suggested propget_walking_upward (PATH, NAME) function
returns two things:
- the value of the property named NAME on PATH, or on the lowest
parent of PATH that has such a property, and
- the path (PATH or one of its parents) where it actually found the
property.
In other words, there's nothing magic about the properties being
accessed this way; it's just an efficiency hack. Instead of a
client-side loop (that we could write today) that walks up the tree
looking for the property, it's a repository-side loop. No changes to
the repository structure or new concepts are involved.
Let's presume that propget_walking_upward could be made to work
off-line. (I don't quite know how to do that, but let's just keep the
issues separate.) Are you sure its semantics aren't the ones you
actually want? They're easy to explain. It's easy to see how to
control it with the existing commands. It's clear how to find all the
state affecting whatever you're trying to do.
You can't say any of those things about the automagic inheritance
mechanisms. There you need some way to show whether a node is
establishing a property's value independently of its parents or merely
inheriting it, so you can see whether changing a parent's value would
affect the value seen at the node. It's a confusing mess.
(By analogy: in C, declarations in outer scopes can be shadowed by
declarations in inner scopes. But you don't talk about an outer
variable having zillions of aliases, one in each scope that is a child
of the one holding its declaration; that's Stroustrupesque. You talk
about variable lookup walking from the point of reference toward outer
scopes, and taking the first thing it finds.
In the end, I suspect that the hair needed to make
propget_walking_upward work offline would be similar to the hair that
would have been needed to get inherited properties working offline ---
but simpler to specify.
And at least in the case where I first wanted it, I actually do want
to know where it originated. It's not a case where it's just a
shorthand for setting a property in lots of places automatically.
That is, I think the searching-upward behavior is my first choice, not
a settle-for-getting-it-working compromise. I'd like to see an
example use --- granting the importance of offline operation --- where
searching upward makes things harder for users.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 9 07:41:46 2005