[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Inheritable Properties

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 15 Feb 2012 14:29:48 -0500

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

> -- 3 -- Should only a subset of children inherit?

All children either inherit or override. (Why are we making this so

> -- 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

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2012-02-15 20:30:25 CET

This is an archived mail posted to the Subversion Dev mailing list.