On Wed, Feb 1, 2012 at 7:38 AM, Julian Foad <julianf...@btopenworld.com> wrote: > Hi Paul. Thanks for indulging my enquiries. > > Paul Burba wrote: > >> Julian Foad wrote: >>> Overriding is done by setting a new value for the inheritable >>> property svn:i:ignore, like this: >>> >>> /subversion svn:i:ignore = *.o *.obj *.a *.lib ... >>> /subversion/trunk/tests svn:i:ignore = *.obj *.a *.lib ... >>> >>> ... which can be done hierarchically; but every such override at a >>> subtree level duplicates much of the information that was provided at >>> the '/subversion' level, which means that whenever we modify the base >>> setting we probably want to look through the whole repository and >>> modify all the subtree settings in the same way. > > Note that my use case in this example is about wanting to *remove* one > pattern from the default list, in a specific subdirectory. > >> On the flip side, if the value of svn:i:ignore on >> /subversion/trunk/tests didn't override, but rather appended to, the >> inherited value from /subversion, > > ... then there would be no way to achieve my use case by setting svn:i:ignore > on the 'tests' subdirectory, unless you provide some as-yet-unmentioned > alternative ... > >> then if we change the base value >> then we *still* need to "look through the whole repository and modify >> all the subtree settings" so that we are no subtree is appending a >> value we *don't* want. > > ... so I don't follow what you're saying here. > > [...] >> Anyhow, while we might currently have different ideas on how best to >> implement "ignores" via inheritable props, your point about taking us >> into the future is a valid one. I'm still not certain "ignores" >> needs to use both explicit and inherited values, but certainly some >> future inheritable property might need both. To that end I tweaked the >> suggested APIs in the wiki to provide this functionality -- the >> callers can decide what they need. > > But how would that work, concretely? I'm asking because the sort of scheme I > had in mind was one where the client would define some syntax to be used > inside an svn:i:ignore property value to specify which patterns should be > added or removed. I don't see how this revised API could support that scheme > recursively.
Ah yes, my suggested API changes are bogus since they only handle the case of a single child and parent both of which have a given inheritable property. But what if there are grand-parents with the same inheritable property? Obviously we need to take those into account if we plan to support the concept of a path having an explicit inheritable property *and* inheriting the same property from a parent. I updated the wiki to reflect this. Paul > Maybe you have a different scheme in mind as a use case. > It's clearly quite tricky to design a useful inherited properties system. > The end result need not be particularly complex, but it is hard to tell by > inspection whether a given design proposal would end up meeting real-life > needs in a reasonably worthwhile way. If we are going to explore the > inherited properties idea further, then > we need to explore how we'd actually use the inherited properties in a > non-trivial example. That's why my original question was (rephrased): > > What would the total design look like, for achieving some particular > example of non-trivial end-user behaviour that could be facilitated by using > inherited properties? > > Last time I asked the question, I meant to suggest exploring an inheritable > reimplementation of 'ignore patterns' as an example, but the discussion got > immediately sidetracked onto how we might implement an ignore-patterns system > that extends and is backward compatible with the existing non-inheritable > 'svn:ignore' property. That's important, of course, but not a particularly > good way to explore the inherited properties design itself. Perhaps it would > be less confusing to base an example on some new, made-up feature. > > As I noted before, it is not a requirement to be able to use inheritable > properties with multi-element values (such as the current multi-line syntax > of svn:ignore) and expect to be able to override/add/subtract single > elements. We could require, say, that any semantic > appending/overriding/subtracting that may be required should be mapped to > whole-property operations. Then, for example, an inheritable > reimplementation of ignore-patterns could make use of multiple props such as > {svn:i:ignore:*.o = yes}, one prop per pattern. A subdirectory could > "subtract" a particular pattern by setting {svn:i:ignore:*.o = no}. And to > make clear that this last thought is not yet a complete solution, at this > point I'd ask how a subdirectory could specify that all ignore patterns > should be cleared/disabled without having to know what all the patterns are. > > - Julian