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.

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.

- Julian

Reply via email to