Re: [RFC] Server Dictated Configuration

On Tue, Jan 17, 2012 at 8:55 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> 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.

Agreed. Let's take repository dictated auto-props and global-ignores
as an example of inherited properties in general.

> 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.

Ok. But we can also dispense with c, as long as we're talking about
inheritable props: we could say that they are always inherited, no
matter what (except if you override them of course).

Which makes me wonder: how will we discern inheritable props from
normal ones? Merely saying that the svn:conf: namespace (for instance)
means that it's always inheritable, will not cut it if we're talking
about a generic feature ...

> 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.

I'm not sure if my suggestion implies the same kind of complexities as
with svn:mergeinfo. But then again, my involvement with subversion
pre-dates merge tracking, so I'm not aware of all the discussions back
then, ideas that were tossed around, ... and I certainly don't have
the same battle-scars and experience with those things as (some of)
you have :-).

But anyway, starting out with an override-only system is perfectly
fine. If it fixes repository-dictated auto-props, it will make a lot
of svn admins (and users) very happy :-). It's still possible to add
some form of extendability later if and when it's deemed useful.

Thanks for your work on this.

-- 
Johan