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 ;)
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
* 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
This should allow legacy clients to read and write props as today.
Once they modify / write props, they won't add svn:inherits (unless
explicitly added by the user). Now the props are active locally
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] ]
- regex controls what files / folders it will be applied to
- 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 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.
Just my €0.02
-- Stefan^2.
Received on 2012-02-07 22:25:35 CET