On Wed, Feb 15, 2012 at 14:29, C. Michael Pilato <cmpil...@collab.net> wrote: > 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.
When your reads become RPCs to a large-scale datastore (say, HBase, Cassandra, Riak, etc) then every extra read "upward" becomes expensive. The ideal is that you have a single RPC for each node you're accessing. Not O(depth). And please don't tell me that caching is the solution. That's a crutch for a poor original design. If you can limit that scan to *just* the relpath of the wcroot, then maybe such a scan is workable as one FS request. IOW, as long as inherited properties don't cause more reads when dealing with nodes. But I fear that *will* be the case. Consider an update for subdir D. You need to scan upwards from D to /, looking for changes in inherited properties. Every single PROPFIND for D will need to perform that scan because it is unclear on whether the client has all the correct parent properties. And thinking on that: how does the client do inheritance in a mixed-revision working copy? D@10 inherits props from P, but the client has P@5. If there are changes in P@7, then the inherited properties a likely wrong for D@10. >... >> -- 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. Yeah. Defer this. I'm not worried about the client implementation at all. We have lots more cycles there. And we typically aren't making RPCs for this (with the caveat of NFS drives :-P ) Cheers, -g
