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