On 02/14/2012 06:48 PM, Paul Burba wrote:
> It seems we are far from any consensus on inheritable properties. The
> major sticking points seem to be as follows:
>
> -- 1 -- Performance: Server Side (a.k.a. "Is this ultimately an
> exercise in futility?")
[...]
> Looking at the server side, I might be oversimplifying, but I don't
> see how this is a performance killer (full disclosure: I've only
> looked at fsfs so maybe bdb is a problem).
I don't see the problem here, either. The server-side search upward is a
bounded operation, and should only really be required for clients examining
the single chain of ancestor directories which exists above a given working
copy's root directory.
> -- 2 -- Can existing properties be made inheritable or are only
> special new "inheritable" properties inhettiable?
We should not try to change the interpretation of any previously existing
property.
> -- 3 -- Should only a subset of children inherit?
All children either inherit or override. (Why are we making this so
complicated?)
> -- 4 -- Backwards Compatibility
You need a new client to get inheritable property support. You might need a
new server to get it, too, depending on how we implement the fallback logic.
For example, there's no reason a 1.8 client couldn't ask a 1.7 server for
properties just as it does today and behave as expected. The one place
where this might get touchy is for 1.7 servers with auth-restricted parent
directories. Where a 1.8 server can say "it's okay to 'leak' inherited
properties on this otherwise unreadable path", a 1.7 server obviously can't
retroactively change its behavior in that way.
> -- 5 -- Inheritance in the Working Copy
>
> There is still much to be determined re how inheritance works within
> the working copy (see Julian's notes in the wiki), but I'm leaving
> this as an open issue until the preceeding items are addressed.
I suspect this will be the single largest point of contention, perhaps not
so much in the desired behavior but in the recommended implementation. That
said, +1 on deferring that conversation until the previous items have found
consensus.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2012-02-15 20:30:25 CET