Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "InheritableAutoProps" page has been changed by pburba: http://wiki.apache.org/subversion/InheritableAutoProps Comment: Create a new wiki spun-off from the InheritableProps wiki, which describes how we ultimately tackled "server dictated configuration" auto-props via inheritable properties. New page: == "Server Dictated Config" Via Inheritable Properties == Many software development shops of non-trivial size desire to have (and to the extent possible, to enforce) a uniform configuration environment among the various clients which commit to their repositories. Although these shops may have some ability to control the environment on the client machines (dictating software versions, etc), expecting humans to consistently set and maintain various runtime configuration parameters in accordance with corporate policy and on every repository-accessing client computer is both error-prone and unscalable. Subversion already provides the means of enforcing much (but not all) of this configuration through the hook script mechanism, but at best this can only punish non-compliant client behavior and clumsily recommend configuration changes (which, again, a human must implement on their client computer). An administrator could save a good deal of time and frustration if they could set a special configuration property on the root <<FootNote(Of course the property need not be set on the root of repository. It might be set on the root of some project folder, e.g. ^/subversion in our own repos, or some other root. The point is that the property doesn't need to be set on every directory to affect the whole repository (or some large subtree) the way that svn:ignore currently requires)>> of their repository which well-behaved clients (treating the special configuration property as inheritable) would use to override the user's local config file settings. {{{#!wiki note "Wait, this sounds familiar..." There really isn't anything particularly "server dictated" about this design at all. It started life as an alternative approach to the server dictated configuration ideas described in http://wiki.apache.org/subversion/ServerDictatedConfiguration and as such a quick read of that original design is suggested. If you've already read that a lot of this will sound familiar since the goals are essentially the same. }}} === Behavioral Specification === New Subversion reserved properties with the prefix "svn:inheritable-*"<<FootNote(Prefer "svn:config-*" or some other option? Don't worry, it's not too late to paint the bike shed a new color)>> will provide additional configuration information that overrides/extends the settings found in the user's run-time configuration. Initially there will be only one such property "svn:inheritable-auto-props". This property will (no surprise!) override/extend the auto-props configuration settings which dictate the properties which are automatically set on newly added or imported files. Unlike traditional auto-props, which can be disabled in the run-time config (i.e. "enable-auto-props = no"), svn:inheritable-auto-props cannot be disabled by a well-behaved client. {{{#!wiki warning "Well-Behaved Clients" and "Trust, But Verify" The configuration dictated by the "svn:inheritable-*" properties can at best be only a suggestion to the client. Older clients will obviously not understand the meaning of these properties and as open source software it is relatively easy for a malicious user to modify a client to ignore these special properties. Given this reality, server-side enforcement of desired behaviors (where possible, and often via hook scripts) is still strongly recommended. }}} === Auto-Props Format === The values of the svn:inheritable-auto-props property are as per the existing run-time configuration auto-props, they contain "any number of key-value pairs in the format ''PATTERN'' = ''PROPNAME''=''VALUE''[;''PROPNAME''=''VALUE''...], where ''PATTERN'' is a file pattern that matches one or more filenames and the rest of the line is a semicolon-delimited set of property assignments. (If you need to use a semicolon in your property's name or value, you can escape it by doubling it.)")<<FootNote(Thank you 'Version Control with Subversion' book, http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea)>> Like the svn:ignore property it only makes sense to set svn:inheritable-auto-props on directories, so attempts to propset the latter on a file will fail. === Auto-Props Hierarchy and Precedence === Any path added to the working copy or imported to the repository must have a previously versioned parent. Both the svn:inheritable-auto-props explicitly set on that parent and the properties inherited by that parent, in addition to the run-time configuration auto-props, will determine the auto-props for the added/imported files under the versioned parent. Where the auto-prop values conflict there are a few simple rules: 1. svn:inheritable-auto-props override the run-time configuration auto-props. 1. svn:inheritable-auto-props inherited from a nearer parent override those from a more distant parent. 1. Explicit svn:inheritable-auto-props override inherited auto-props. Auto-props are overridden by individual file pattern. This means the if a run-time config defines auto-props for several different file patterns (say *.c, *.h, and *.py) and a single pattern (*.c) is defined in a svn:inheritabled-auto-props property at the root of the repository, then only the *.h and *.py auto-props from the run-time config still apply, only the *.c value is overridden. For example if we have this run-time config: {{{ [miscellany] enable-auto-props = yes [auto-props] *.c = svn:eol-style=native *.h = svn:eol-style=native *.py = svn:eol-style=native }}} And a repository with this heirarchy and svn:inheritable-auto-props set as shown: {{{ / svn:inheritable-auto-props = '*.bat = svn:executable' /ProjX svn:inheritable-auto-props = '*.c = svn:eol-style=CRLF' '*.h = svn:eol-style=CRLF' /ProjY /ProjZ }}} If we check out ^/ProjX and add the files 'bar.py', 'baz.c', and 'foo.bat': {{{ >svn pg svn:inheritable-auto-props -vR --show-inherited-props Properties inherited from '%ROOT-URL%': svn:inheritable-auto-props *.bat = svn:executable Properties on '.': svn:inheritable-auto-props *.c = svn:eol-style=CRLF *.h = svn:eol-style=CRLF >svn st ? bar.py ? baz.c ? foo.bat >svn add bar.py baz.c foo.bat A bar.py A baz.c A foo.bat }}} Thee file 'bar.py' has its automatic svn:eol-style dictated by the auto-props for *.py which exist soley in the run-time configuration. While bar.py has parents with the svn:inheritable-auto-props property, none of them have a matching pattern, so there is no override. The file 'baz.c' gets its auto-props from the svn:inheritable-auto-props set on '.', which override those set for the same pattern in the run-time config. Lastly the file 'foo.bat' gets its auto-props from the svn:inheritable-auto-props property set on the root of the repository. Even though svn:inheritable-auto-props is set on foo.bat's nearest parent '.', there is no matching pattern, so the no override occurs and the next nearest parent with svn:inheritable-auto-props applies. {{{ >svn pl -v bar.py baz.c foo.bat Properties on 'bar.py': svn:eol-style native Properties on 'baz.c': svn:eol-style CRLF Properties on 'foo.bat': svn:executable * }}} {{{#!wiki warning If multiple patterns, defined at different levels (i.e. the run-time config and multiple parent's svn:inheritable-auto-props) all match a given file, then, like multiple matching patterns within the run-time config, there is no guarantee that auto-props will be applied in any partiuclar order. One rule only overrides another rule if they have the exact same pattern. }}}
