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

Reply via email to