On Tue, Feb 7, 2012 at 4:24 PM, Stefan Fuhrmann <eq...@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<ptbu...@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.
