On Wed, Feb 1, 2012 at 8:46 AM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Wed, Feb 1, 2012 at 1:38 PM, 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. 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. >> > > Perhaps this issue can be deferred if the API would allow you to get / > cache all the inheritable props, up to the repository root (since they > are always readable anyway, regardless of authz). Not only "up to the > nearest path-wise ancestor that has the property", but "give me > everything up to the root".
Yes, this is what I should have done when tweaking the APIs last night, I had my head buried in the overly simple case of child-parent and forgot about those other pesky ancestors. I adjusted the suggested APIs in the wiki so they can get *all* path-wise ancestors with inheritable properties. > Then the concrete consumer of the prop can > always add special syntax and corresponding inheritance / override / > append behavior specific to its uses (a special syntax that defines > how the multiple inherited props are to be "overlayed"). Exactly. Let the callers decide. > OTOH, a standardized syntax and corresponding defined behavior might > be nice though. I'm just a little bit afraid that it's difficult to > standardize something syntax-like, because prop values can have so > many different uses, syntaxes, interpretations, ... depending on what > they are for. +1 > Some previous mails in this thread also contain some discussion about > "override" vs. "append", where I suggested for instance to use > something OO-like for the syntax of the prop value, like e.g. using > '$super' to refer to the inherited value. Then you can have > 'svn:i:ignore=$super *.o *.pyc' (append) or 'svn:i:ignore=*.o *.pyc' > (override). With the default being an implicit '=$super'. You wouldn't > be able to block out a single value of a multi-value inherited prop > though (like only deleting '*.o', but not the rest of the inherited > ignore pattern). And the situation also gets more complex if you put > the full "auto-props" value in a single prop, which then contains > multiple multi-values etc ... > > -- > Johan