On Wed, Feb 1, 2012 at 7:38 AM, 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.

Ah yes, my suggested API changes are bogus since they only handle the
case of a single child and parent both of which have a given
inheritable property.  But what if there are grand-parents with the
same inheritable property?  Obviously we need to take those into
account if we plan to support the concept of a path having an explicit
inheritable property *and* inheriting the same property from a parent.
 I updated the wiki to reflect this.

Paul

> 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

Reply via email to