On Mon, Jan 30, 2012 at 11:05 AM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> Branko Čibej wrote:
>
>> On 27.01.2012 12:53, Julian Foad wrote:
>>> Branko Čibej wrote:
>>>> On 27.01.2012 11:50, Julian Foad wrote:
>>>>> We need to see how we'd implement a reasonable system of svn:ignores
>>>>> and auto-props using the proposed inheritable properties system. The
>>>>> ability to see the inherited value and then merge in a child-defined
>>>>> value [...] is essential if we're going to implement these features
>>>>> using properties with semantics like the existing 'svn:ignores'. [...]
>>>>
>>>> No, you need to give the inherited properties that carry server-dictated
>>>> configuration a different name, don't you think? Whether the merging is
>>>> then done server-side or client-side is almost a bikeshed.
>>>
>>> I'm not quite sure what you mean. Could you give a specific example?
>>>
>>> [...] One way to achieve server-dictated configuration of ignores would
>>> be to make the server control the 'global-ignores' [config setting].
>>> But for the purposes of exploring inheritable properties, let's ignore the
>>> 'global-ignores' config setting and assume that we're going to
>>> control the ignores through (inherited) properties alone. [...]
>>
>> Heh, but I fail to see a semantic difference between the two cases. :)
>
> An
> "inherited properties" design implies client-side setting of the
> inherited properties, whereas the design for server-dictated
> configuration implies that setting will be done server-side by an
> administrator. For either approach, I would ask: how would you go about setting up a useful
> hierarchy of ignore patterns? In the server-side case, you can say we'll just start with a simple config file format
> and defer that problem; somebody can design a more powerful config system for the administrator to use, later. So I
> asked specifically about how one would conveniently define
> ignore-patterns hierarchically in a generally useful "inherited
> properties" design.
>
>> Since the server-dictated global-ignores would only apply to a certain
>> subtree in the repository, it would /already/ behave as if it were an
>> inherited svn:ignore property, and what's more, would be implicitly
>> merged by existing client implementation with any svn:ignore properties
>> that subtree happens to contain.
>
> No. The way I read the proposed 'server-dictated config' scheme, it didn't include a way to configure different values for 'global-ignores' to apply to different
> directories inside the WC, only for transmitting a single value of
> 'global-ignores' which could depend on the root directory of the WC.
That is incorrect, the server dictated configuration proposal
(http://wiki.apache.org/subversion/ServerDictatedConfiguration)
supports different configuration values by path:
[[[
Behavioral specification
The high-level behavior for server-dictated configuration is
relatively simple: the repository maintains a list of configuration
parameters and values which, as necessary, the server provides to the
client. The client, then, behaves in accordance with the
server-dictated configuration.
Subversion could recognize multiple levels of possible hierarchy in
the server-side configuration: server-wide, per repository, or per
repository-path. The current plan is to allow configuration at the
most granular level, per repository-path.
]]]
Paul
> But anyway, my point was to explore how useful the inherited properties idea would be in general, using ignore patterns as an example. If you're suggesting that this example of an inherited 'global-ignores' value being augmented by a non-inheritable 'svn:ignore' value should serve as a general model for how overriding should be done in an inherited properties system, that's a valid suggestion but it doesn't look like an elegant one.
>
> - Julian
Received on 2012-01-30 17:57:54 CET