On Thu, Nov 1, 2012 at 10:00 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Stefan Sperling wrote:
>
>>> <tt>svn:inheritable-auto-props</tt>
>>> +property overrides/extends the <tt>auto-props</tt>
>>> configuration setting.
>>> +The <tt>svn:inheritable-ignores</tt> property extends the
>>> +<tt>global-ignores</tt> configuration setting as well as the
>>> +<tt>svn:ignore</tt> property.</p>
>>
>> Hey Paul,
>>
>> svn:mergeinfo is also inheritable (ignoring subtle differences in
>> inheritance semantics), yet we don't call it svn:inheritable-mergeinfo.
>>
>> So I'm wondering if we can find better names for these new properties.
>>
>> What about svn:default-ignores and svn:default-auto-props?
>> Or perhaps names which correspond to the configuration file counterparts,
>> svn:global-ignores and svn:auto-props?
>
> There is certainly a benefit to keeping the name short and simple.
>
> I agree with Stefan's premise that we don't need to include
> "inheritable" in the name just because it is. "Inheritable-foo" sounds
> like this is some strange new thing -- which it is, today -- but in the
> future I totally expect the use of inheritable properties to be common
> and mundane, and the prefix will sound clumsy and old-fashioned.
>
> So +1 on "svn:auto-props".
I proposed the same in the thread Paul linked to. I cannot recall if
there was a convincing counter argument or we just settled on the
names Paul went with.
> For ignores, I have an alternative proposal. Instead of adding a second property name, may I suggest keeping the existing property name and extending the syntax of its value.
>
> Currently
>
> svn:ignore =
> Makefile
> *.obj
>
> applies those two patterns to the immediate children only.
I do not agree with this one. I think you are overlooking that the
the inheritable properties are merged together with closest property
having precedence. I do not see how you can do that with the existing
svn:ignore property in any way that is useful without changing the
behavior. I like the idea of a new property for this.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-11-01 15:08:38 CET