On Wed, Feb 1, 2012 at 7:38 AM, 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.
Hi Julian,
Does the latest version of the proposed APIs address your concerns?
We can ask for a path's explicit mergeinfo and the inheritable
properties it inherits from its path-wise ancestors (not just the
path's closest parent, but *all* its parents going all the way to the
root of the repository). It seems to me this is sufficient to
implement any of the inheritable property rules we might dream up for
a particular inheritable property.
Paul
> 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
Received on 2012-02-07 00:14:56 CET