On Tue, Jan 31, 2012 at 12:48 PM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> Paul Burba wrote:
>
>> Julian Foad wrote:
>>> The ability to see the inherited value and then merge in a child-defined
>>> value (adding/subtracting/overriding semantic sub-elements within the
>>> property value) is essential if we're going to implement these features
>>> using properties with semantics like the existing 'svn:ignores'.
>>
>> Why do we need to subtract and override? [...]
>>
>> 5) [...] we take a path's inherited (or explicit) svn:i:ignores
>> property value, the svn:ignore property (if any) on a path's
>> parent directory, and the global-ignores runtime config value and
>> append all three together to get the final answer on what to ignore.
>>
>> I take it you view this as insufficient?
>
> This hybrid approach to defining the ignore patterns by means of one inheritable property and a different non-inheritable property gives us in total the ability to both override and append.
>
> 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.
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 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. Append or override, there's not getting around
the administrative hassle of subtree properties.
> Appending is done by a non-inheritable svn:ignore property, like this:
>
> /subversion/trunk/tests/libsvn_client svn:ignore = *-test *-test.exe *-tester *-tester.exe
> /subversion/trunk/tests/libsvn_delta svn:ignore = *-test *-test.exe *-tester *-tester.exe
> /subversion/trunk/tests/libsvn_diff svn:ignore = *-test *-test.exe *-tester *-tester.exe
> /subversion/trunk/tests/libsvn_...
>
> ... which can't be done hierarchically: we can't append the '*-test...' patterns just once at the '/subversion/trunk/tests/' directory level.
>
> So the result is better than what we have now, for ignore patterns. If that's all we need, fair enough. But if we're designing a feature to take us into the future, not just for svn:ignore, and if that's the best general usage pattern we can achieve, I feel we ought to be aiming for better.
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.
Paul
>
> - Julian
Received on 2012-02-01 08:20:42 CET