On Mon, Jan 16, 2012 at 5:51 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> Hi All,
>
> I haven't been ignoring this thread, I've been laid low with illness
> the last couple of weeks...
Yikes! Hope you're feeling better.
> ...Anyhow, when I finally got back to this I see that a lot of folks
> are itching for an inheritable property solution. So for now I'll
> defer on the open questions re the proposal in the wiki. Instead
> let's talk inherited properties. I suspect that if we don't view
> inheritable props through an "everything an pony too" lens, if we
> agree on some basic limitations and easy to explain, well-defined
> behavior, then we can make this work[1].
>
>
> [1] Understand that I am emotionally scarred from implementing
> mergetracking/mergeinfo, where we tried to include the pony. We got
> the pony in, but it trampled me on its way -- I don't want to go down
> that road again!
And we ended up getting a shetland / clydesdale hybrid, with it's own
set of warts. :P
...
> On Thu, Jan 5, 2012 at 4:52 PM, Hyrum K Wright
> <hyrum.wright_at_wandisco.com> wrote:
>> As I recall, there were a few reasons why inherited properties haven't
>> been implemented. One is the client-side storage and lookup, which
>> wc-ng has helped with. The other is what to do with non-checked out
>> parent directories, which you mention above. Another problem is the
>> various authz issues, similar to the infamous issue 3242 problems we
>> had with copy and move.
>
> Maybe we can make a special case for inheritable properties, simply
> state that by definition, if you set an inheritable property on a
> path, then users, even those who don't have access to the path, but do
> have access to the path's children, can inherit the property.
>
> For example if a user has access to foo/bar/baz, then that user can
> inherit properties from foo, even if he doesn't have access to foo
> itself. All the repository has to tell the client is, "Path
> foo/bar/baz inherted property NAME=VAL", it doesn't even need to say
> where it came from.
>
> If we don't make this exception then it seems to me that inheritable
> properties are dead in the water, at least as far as being a useful
> solution to "server" dictated auto-props and global-ignores.
After having gone through the wc-ng experience, alarm bells start
ringing every time somebody says "we can make a special case for ...".
Please, please, please consider if that's really needed, of if a more
generalizable solution is appropriate. (And maybe what we're talking
about here is a generalized solution for inheritable props. :) )
Another thing to note is that there have been some rumblings about
authz improvements, along the lines of an additional permission to say
"you can know about this directory". I know C-Mike has been thinking
about this off-and-on since the 3242 debacle, and something like
inheritable props my fit in that model, though I'd had to make the
feature dependency tree another level deeper.
>> And lastly, we haven't yet hammered out the
>> issues surrounding what to do with potentially conflicting properties
>> within the tree--though that might have been specific to log message
>> templates, now that I think about it.
>
> We could chose to make things simple and follow the svn:mergeinfo
> model of inheritance:
>
> a) If a path has an explicit given property then it doesn't inherit
> that property; the explicit value is the complete value.
>
> b) If a path doesn't explicitly have a given property then it inherits
> that property from its nearest parent with the property explicitly set
> on it.
>
> No merging of inherited with explicit properties, so no conflicts,
> just keep it simple.
What if there are multiple applicable paths?
Consider a commit in which two files are committed and they each have
different svn:inherit:log-message properties at equal levels of
priority. If either file was committed separately, the result would
be clear, but together it creates ambiguity. I don't know the answer
to this question, and I maybe it's as simple as "pick one" or "cat all
the values together." I'm just saying that while the result doesn't
have to be sensical, it should at least be defined.
> Essentially the same approach for svn:auto-props and
> svn:global-ignores, we do the same thing the current hierarchy of
> configuration does today: There is no merging of lower priority
> configuration, it's simply a matter of choosing the option value from
> the highest priority level the option is specified.
>
> Which would be, from highest to lowest priority:
>
> Command-line options*
> Explicit/inherited svn:auto-props/svn:global-ignores
> Per-user runtime configuration (${HOME}/.subversion/*)
> The per-user Registry values (Windows Only)
> Per-machine runtime configuration (/etc/subversion/*)
> The system-wide Registry values (Windows Only)
>
> * Yes Johan, your arguments for making CL options have the highest
> priority did sway me :-)
...
One other thought: if we are going to implement these as properties,
and we're going to store them as properties, and we're going to
transmit them (through the editor) as properties, let's please make
sure they *are* properties. In working on Ev2 recently, I discovered
the fact that one of the ways we remove stale lock tokens on the
client is by deleting a non-existant property. For reasons I won't go
into here, this violation of property semantics is essentially
implementation-dependent, and causes all kinds of headaches when the
implementation changes. Let's not make the same mistake with
inheritable properties.
-Hyrum
PS - Thanks for all the work on this issue / sorry I'm just chiming in
the from the peanut gallery. :/
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-01-17 02:28:35 CET