On Sat, Jan 21, 2012 at 9:05 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On Thu, Jan 19, 2012 at 03:23, Paul Burba <ptburba_at_gmail.com> wrote:
>> 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.
>>
> Another option is make caller to know how to handle properties. I.e.
> introduce call like svn_get_inhertiable_prop(wc_path, propname)
> returning chain of configured properties with repos_path starting from
> given wc_path. For example call to
> svn_get_inheritable_prop("wcroot/foo/bar", "property") return:
> /repos/project/trunk/foo -> value1
> /repos/project/trunk -> value2
> /repos/ -> value3
>
> Then caller may implement any logic to merge them. At implementation
> level we can store all properties and WC root (and for each switched
> root).
Hi Ivan,
Are you suggesting that any property is inheritable simply by asking
it to be so? What we are talking about here is a way to differentiate
inheritable vs. non-inheritable properties (or as Johan put it:
"discern inheritable props from normal ones").
It sounds to me as if you are proposing there be no such concept of
"inheritable" vs. "non-inheritable" properties. If that is the case,
then *all* properties are potentially inheritable, not just those that
were *intentionally* created as inheritable. The problem with this is
that users could then see what properties exist on paths they don't
have read access to. I've made my argument earlier in this thread as
to why I think *inheritable* properties set on an unreadable parent
should be inherited by a readable child, but this logic doesn't extend
to any arbitrary property.
Paul
> Ivan Zhakov
Received on 2012-01-23 18:17:26 CET