subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@btopenworld.com>
Subject Re: [RFC] Server Dictated Configuration
Date Wed, 01 Feb 2012 12:38:30 GMT
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

Mime
View raw message