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
>> (adding/subtracting/overriding semantic sub-elements within the property value)
>> is essential if we're going to implement these features using properties
>> with semantics like the existing 'svn:ignores'. To do that, we will
>> need APIs that can fetch the inherited value and the explicitly defined value
>> for the same path as two separate values, so that the client code can combine
>> them according to its own rules.
>>
>> 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?
>
> I used the 'ignores' functionality in my example and was about to suggest you do the same, but there's a source of confusion: we currently have two completely different ways to specify ignores (client config 'global-ignores', and 'svn:ignore' property on a directory). One way to achieve server-dictated configuration of ignores would be to make the server control the 'global-ignores' setting in the client configuration, as in <http://wiki.apache.org/subversion/ServerDictatedConfiguration>. 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. That's what I was assuming when I showed my "{ svn:i:ignore:*.pyc, ... }" example.
Heh, but I fail to see a semantic difference between the two cases. :)
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.
So then, if someone wants to have different inherited global ignores,
deeper down, one can add them.
Of course this doesn't quite cover all the use cases, specifically the
one where you want to just extend any existing global ignores, which
your svn:i: namespace seems to provide. However, when you say
"automatically merge", remember that merge can be additive or
subtractive ... so ... your svn:i: still doesn't cover all the use
cases, you'd have to, e.g., introduce svn:add:ignore and svn:del:ignore.
At which point I begin to wonder if this part is even worth the extra
complexity.
-- Brane
Received on 2012-01-27 17:15:27 CET