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