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
