subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Burba <>
Subject Re: [RFC] Inheritable Properties
Date Wed, 08 Feb 2012 22:08:53 GMT
On Tue, Feb 7, 2012 at 4:24 PM, Stefan Fuhrmann <> wrote:
> On 07.02.2012 00:41, Greg Stein wrote:
>> In most data storage mechanisms for the repository, inheritable
>> properties are a performance killer.
> I'm not sure that this is actually applicable to SVN
> for two reasons:
> (1) we use deltification and
> (2) we often handle whole file trees
> (1) causes us to do typically 5 .. 10 I/Os per file access.
> So, adding 5 .. 10 checks on parent folders is not an
> outrageous overhead.
> (2) not only means that most of the overhead vanishes
> by passing the parent info down the recursive op. It also
> can make inherited props *cheaper* in the case that
> most nodes won't come with local prop values.
>>  Bill Tutt advised us against
>> inheritable properties years ago for exactly this reason. It is one of
>> the main reasons that we never implemented them. Good data modeling
>> for path-based inheritance is very difficult, and can put a lot of
>> constraints on your implementation. Bill noted that NTFS does not have
>> inheritable properties for perf reasons: instead, property changes
>> (notably, ACLs) are copied down to the N child, recursively, under the
>> altered node.
>> Consider any PATH ->  DATA mapping for the storage. You now have to
>> decompose PATH into N segments and issue N-1 more queries to look for
>> inheritable properties.
> Yes, the local w/c data storage issue may be harder to
> do efficiently.
>> I know that Hyrum is looking to use a key/value datastore in a future
>> FS backend. Inheritable properties could well make that project a
>> performance non-starter.
> I happen do have done some initial designs on this as well
> and it seems that prop inheritance may not be specifically
> hard. If we want to implement ACLs, those may need just
> the same inheritance mechanisms as inherited props.
>> Cheers,
>> -g
>> On Mon, Feb 6, 2012 at 18:15, Paul Burba<>  wrote:
>>> Hi All,
>>> There has long been a desire for Subversion to support some form of
>>> inherited properties.  Recently, while discussing a potential solution
>>> for server dictated configurations (see
>>>, the idea of using
>>> inheritable properties as an alternative approach was raised.  To that
>>> end I put together an inherited properties design wiki, see
>>> Many of you have already seen this wiki and weighed in on the server
>>> dictated config thread, but in the event you haven't please check it
>>> out.  I'd like to move this forward or return to the original server
>>> dictated config, so any questions, concerns, and/or suggestions are
>>> greatly appreciated.
> Sure, here we go ;)

Hi Stefan, Thanks for the feedback, responses below...

> I think the most problematic part of your proposal is backward
> compatibility as Daniel already pointed out. On a meta level,
> this may also be taken as a general weakness in your model
> that it does not interact well a proven, well-established model.
> Without having thought too much about it, here is some
> counter proposal that might work better:
> * by default existing and future props behave as today

Meaning that "inheritable" properties are just like any regular
versioned property in 1.7 as regards setting, getting, server-side
storage, and client-side storage?

> * a new svn:inherits property (just this one) controls which props
> will be propagated to sub-folders and will itself not be propagated
> * propagation will exclude / ignore a node that has props but no
> svn:inherits setting

Do we need to set svn:inherits on every directory?  Or just at the
root of the subtree we want some inherited properties to apply to?

Could you be specific about what you mean by "propagation".

> This should allow legacy clients to read and write props as today.

That is no different from what I've proposed that I can see.  Do you
disagree?  Perhaps the wiki needs to be clarified.

> Once they modify / write props, they won't add svn:inherits (unless
> explicitly added by the user).

"They" refers to legacy clients?  New clients that understand
svn:inherits?  Something else entirely?

> Now the props are active locally

When (or what) does "Now" refer to.  What are locally active props?

> but won't be propagated within the sub-tree. Instead the inherited
> props from parents will still be visible within the sub-tree.
> Now, what could prop inheritance look like? The thing is that
> we should have the option to specify file-type specific settings /
> props high up in the repo tree. Suggested format for svn:inherit
> * N lines, each containing a single rule
> * a rule adding / replacing properties to be passed down takes the
> following form of
> add propName [propValue [regex] ]

What does propValue control?  Is an inheritable property potentially
inheritable only if it has a certain value?

> - regex controls what files / folders it will be applied to

So an inheritable property might not be inheritable by all children?

> - if propValue is not given, propName must refer to some
> existing prop on this directory
> - takes affect at the current node
> * a rule to stop propagation *in the subtree* might look like this
> remove propName
> * a rule to exclude a specific setting for only this node
> ignore propName
> * multiple rules for the same propName are allowed and will be
> applied in order of declaration
> Local prop settings

"Local prop settings": Do you mean properties explicitly set on a path
or local prop changes?

> will never be modified nor overwritten by
> inherited props. To propagate a different value, just need to put
> an "add" rule in svn:inherits on that node.

Sorry for all the questions, I'm simply having a tough time following
you :-\  Maybe you could describe how your approach would work in a
simple case like this:

Let's say we have a new property svn:ignores, which is similar to
svn:ignore but we want to to be inheritable across an entire subtree,
not just for the immediate children of the directory it is set on.
Say each top-level project in the ASF repository wants it's own
particular value of svn:ignores, but that within each project the
value for this property is consistent.  Looking at just what would we set to
accomplish this?

> Just my €0.02
> -- Stefan^2.

View raw message