On Tue, Jan 17, 2012 at 5:02 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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).
I was being a bit pedantic in c). I only meant that one possible
state is that the property in question is literally not set
*anywhere*.
> 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 ...
Yeah, I've been thinking about this. As you say, the solution for our
"own" inheritable properties is simple. Since Subversion already
reserves properties beginning with "svn:" for its own use we could
just extend it and say anything beginning with "svn:inheritable:" is
inheritable.
But for custom user properties? Ugh, yet again I see why this feature
has been avoided :-) Either we declare that customer user properties
names starting with some arbitrary string ("inherited:"?) will be
treated as inherited or we require that inheritable properties be
explicitly created as inheritable (i.e. some new option to propset and
propedit). The latter of course means we'll have to make changes to
the backends and wcng to store this new trait. The former means that
we might make existing custom properties that share our chosen prefix
into inheritable properties...
...Or maybe we invite users into our "svn:" namespace. Let them use
the "svn:inheritable:" prefix while we reserve the "svn:i:" prefix for
our own use. Seems like that would work.
~~~~~
I've also been pondering a closely related issue, namely how to
differentiate between an explicitly set property and an inherited one.
What I mean is this, say we have this working copy:
branch-wc/
branch-wc/src/
branch-wc/src/main.c
Further, let's suppose the inheritable property
"svn:inherit:auto-props", with the value "*.c=svn:eol-style=native",
is set on branch-wc/src. If we ask what properties are on
branch-wc/src the output is obvious:
>svn pl -v src
Properties on 'src':
svn:inherit:auto-props
*.c=svn:eol-style=native
Now if we ask what properties are found on src\main.c, we all (I
hope!) expect to see both the properties explicitly set on main.c, as
well as those inherited from src:
>svn pl -v src\main.c
Properties on 'src\main.c':
svn:eol-style
native
svn:inherit:auto-props
*.c=svn:eol-style=native
But how does a user differentiate between an explicit and inherited
property? We'll need to flag it somehow. For proplist this is
relatively easy:
>svn pl -v src\main.c
Properties on 'src\main.c':
svn:eol-style
native
Inherited properties on 'src\main.c':
svn:inherit:auto-props
*.c=svn:eol-style=native
>svn pl src\main.c
Properties on 'src\main.c':
svn:eol-style
Inherited properties on 'src\main.c':
svn:inherit:auto-props
But for propget it's a bit more difficult:
>svn pg svn:inherit:auto-props src
*.c=svn:eol-style=native
>svn pg svn:inherit:auto-props src\main.c
*.c=svn:eol-style=native
Also, how does a --recursive propget or proplist work? Does it show
every path under src as having the "svn:inherit:auto-props" property?
While that may be accurate, it's excessive. We'd probably only want
to show inherited properties on the root of the target path and let
the rest be implied.
Maybe the solution is that both propget and proplist don't show
inherited properties by default, and only show them with a new option
(--inherited?).
Anyway, I don't want to beat this to death, if this is the least of
the problems with inheritable properties I'll be happy.
Paul
>> 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
Received on 2012-01-19 00:24:27 CET