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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
