On Tue, Jan 17, 2012 at 12:51 AM, Paul Burba <ptbu...@gmail.com> wrote:
[...] > We could chose to make things simple and follow the svn:mergeinfo > model of inheritance: > > a) If a path has an explicit given property then it doesn't inherit > that property; the explicit value is the complete value. > > b) If a path doesn't explicitly have a given property then it inherits > that property from its nearest parent with the property explicitly set > on it. > > No merging of inherited with explicit properties, so no conflicts, > just keep it simple. I'm just thinking out loud here, but what about the following approach: - These new svn properties (e.g. all properties in de 'svn:conf:' namespace) are always *inheritable*. - But whether or not they are *inherited* (and in what way) is up to the sub-tree. 'In what way': I'm thinking about inheritance vs. extending/appending vs. override. I'm thinking a bit along the lines of OO-languages: some special syntax or keyword in the subtree's property signals that the property must be inherited. Let's say we use '$super' to point to the inherited prop, and if the prop is not specified, '=$super' is implied, then we could do: ^/ -> svn:conf:ignore = *.o *.lo *.la *.al .libs ^/native-app -> no prop needed ($super is implied) # inherit ^/native-app/python-mods -> svn:conf:ignore = $super *.pyc # append ^/java-lib -> svn:conf:ignore = *.class # override ^/java-lib/python-mods -> svn:conf:ignore = $super *.pyc # append Or something like that. The situation would be more complex for 'auto-props', depending on how we choose to model that: as a single multiline property (svn:conf:auto-props), or as a set of properties, one for each 'pattern' ('svn:conf:auto-props:*.c = svn:eol-style=native', 'svn:conf:auto-props:*.java = svn:eol-style=native', ...). The latter looks more like how it's currently structured in client-side config. In the multiline case, we might like to make it possible to inherit everything ($super), but also to specify inheritance of individual 'patterns' out of the multiline prop (something like 'svn:conf:auto-props = *.c = $super(*.c) \n*.java = ...'). Hmmm, that gets complicated ... I'll stop here with thinking out loud :-). > Essentially the same approach for svn:auto-props and > svn:global-ignores, we do the same thing the current hierarchy of > configuration does today: There is no merging of lower priority > configuration, it's simply a matter of choosing the option value from > the highest priority level the option is specified. > > Which would be, from highest to lowest priority: > > Command-line options* > Explicit/inherited svn:auto-props/svn:global-ignores > Per-user runtime configuration (${HOME}/.subversion/*) > The per-user Registry values (Windows Only) > Per-machine runtime configuration (/etc/subversion/*) > The system-wide Registry values (Windows Only) > > * Yes Johan, your arguments for making CL options have the highest > priority did sway me :-) > > On Fri, Jan 6, 2012 at 7:16 AM, Johan Corveleyn <jcor...@gmail.com> wrote: >> Come to think of it: using properties has the nice advantage that >> these "configurations" come along when a project is branched or >> tagged. Which is what most users would expect, I guess. > > Except when they don't expect it... > > The configurations would certainly come along if the path on which > they were explicitly set was copied (just like any other versioned > prop), but I don't think inherited properties should be copied, > because then if the inherited properties on the destination differ > from the copy source, then we'll need...wait for it...explicit subtree > inherited properties on the destination (i.e. explicit properties that > appear, seemingly from nowhere, on the copy destination). > > Properties popping into existence has proved quite confusing with > svn:mergeinfo, where it is regrettably necessary in some cases, but > for generic inherited properties do we really need this behavior? Why > not simply state that inheritable properties are handled *exactly* > like any other versioned property w.r.t. copies and moves, so users > should plan accordingly. > > I don't mean to imply that there won't be cases where we might prefer > to have inherited properties copied, it's just that neither approach > is perfect for every use case, so why not go with the behavior that is > simpler to implement, simpler to explain, and doesn't sprout new > properties out of the ether? I agree we shouldn't be doing any special copying of inherited props that come from higher up the hierarchy than the branch-root. But I think that's not needed, if we clearly state that we limit the property inheritance to only path-wise hierarchy (not historical ancestry). So if a property is inherited because it's set on a path that's higher up the hierarchy than the branch-root, it will still apply to any new branches that are part of that same '(grand-)parent-path'. Properties set on ^/subversion will apply to trunk, as well as to all branches and tags that are created under ^/subversion. No need to do any copying. (Ok, if you copy to a subtree outside of ^/subversion, those properties no longer apply). Properties set on ^/subversion/trunk will naturally be copied along just like any other property, when you 'svn cp ^/subversion/trunk ^/subversion/branches/whatever'. I don't see a problem with that. -- Johan