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