On Tue, Jan 17, 2012 at 12:51 AM, Paul Burba <ptburba_at_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 <jcorvel_at_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
Received on 2012-01-17 14:34:14 CET