Repository Dictated Configuration Via Inheritable Properties
| Table of Contents |
|---|
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.
...
| Info |
|---|
"Wait, this sounds familiar..." This effort 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. |
...
The values of the svn: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:auto-props on directories, so attempts to propset the latter on a file will fail.
...
The values for the svn:global-ignores property are in the same format as the svn:ignore property: a newline-delimited collection of file patterns.
| Footnote |
|---|
At the time when 1.8 was released, the release notes and this page incorrectly said the format was the same as configuration defined global-ignores: that is, whitespace-delimited. |
Like svn:auto-props, the svn:global-ignores property can only be set on directories.
...
- svn:auto-props override the run-time configuration auto-props.
- svn:auto-props inherited from a nearer parent override those from a more distant parent.
- Explicit svn: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: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.
...
- The global-ignores section of the runtime configuration.
- Any svn:global-ignores properties explicitly set on, or inherited by, the path.
- The svn:ignore property, if any, set on the path's immediate parent.
There is no actual hierarchy among these ignore sources, the patterns found in each are simply combined, they do do not override each other.
...