On Tue, Feb 7, 2012 at 4:24 PM, Stefan Fuhrmann <eqfox_at_web.de> 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<ptburba_at_gmail.com> 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
>>> http://svn.haxx.se/dev/archive-2012-01/0032.shtml), the idea of using
>>> inheritable properties as an alternative approach was raised. To that
>>> end I put together an inherited properties design wiki, see
>>> http://wiki.apache.org/subversion/InheritedProperties
>>>
>>> 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
https://svn.apache.org/repos/asf/subversion what would we set to
accomplish this?
> Just my €0.02
> -- Stefan^2.
Received on 2012-02-08 23:09:27 CET