On Tue, Jan 17, 2012 at 8:33 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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.
Hi Johan,
(The following may be the same as what you describe above, but just to
be clear...)
Let's keep in mind we (or at least I :-) have been talking about two
closely related, but ultimately separate ideas:
1) Generic inherited properties
2) How to use inherited properties to facilitate repository-dictated
auto-props and global-ignores.
Viewed from the perspective of #1, a subtree either:
a) Explicitly has a property set on it
b) Doesn't have that explicit property but inherits it from a path-wise ancestor
c) Doesn't have the the explicit property nor does it inherit it from
any ancestor.
Those are the only three options. A subtree in the repository doesn't
get to say whether or not in inherits a given property or not, either
it does or does not by definition. Now as to what to *do* with this
particular property...
...Once we start talking about #2 (or any other particular instance of
an inheritable property), then we can imagine that different semantics
come into play depending on the particular property and the context in
which it is used. A subtree may inherit a given property, but what
the client code decides to do with this value (ignore it, use it as
is, merge it with something else, etc.) depends on context.
> 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.
Hmmm, maybe, but as I've mentioned elsewhere, it's these types of
complexities that have kept inheritable properties from being
implemented before now. I can readily vouch for the fact that the
non-inheritable vs. inheritable concept used with svn:mergeinfo, while
it works, is difficult for users to understand and has been the cause
of many an edge case bug. So as far as *generic* inheritable
properties go I still prefer the override-only model.
> 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).
Exactly, we leverage the property's inheritability by judiciously
setting it at the highest possible point in the tree, which is likely
to be the repository root or a project root. If you a particular
branch has need of it's own particular configuration then explicitly
set the properties on the root of the branch.
Paul
> 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 20:56:04 CET