On Wed, Feb 1, 2012 at 1:38 PM, Julian Foad <julianfoad_at_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". 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").
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.
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
Received on 2012-02-01 14:47:04 CET