Re: [RFC] Server Dictated Configuration

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

-- 
Ivan Zhakov