subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Burba <>
Subject Re: [RFC] Server Dictated Configuration
Date Wed, 01 Feb 2012 01:44:02 GMT
On Tue, Jan 31, 2012 at 12:48 PM, Julian Foad
<> 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
> 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.


> - Julian

View raw message