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.
Received on 2012-01-17 23:03:05 CET