On Thu, Nov 1, 2012 at 10:00 AM, Julian Foad <julianf...@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/
