Re: [RFC] Server Dictated Configuration

On Mon, Jan 23, 2012 at 21:16, Paul Burba <ptburba_at_gmail.com> wrote:
> 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").
>
Yes, that's exactly what I proposed. But I'm fine with idea
differentiate properties behavior using dedicated namespaces (svn:i
and svn:inheritable:).

-- 
Ivan Zhakov