On Mon, Jan 30, 2012 at 11:05 AM, Julian Foad <julianf...@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
