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". 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. Something like svn:ignore = Makefile .../*.obj could mean the immediate child "Makefile", and "*.obj" in any directory (at any depth below here), where ".../" is a special syntax that can be used at the beginning of a pattern to mean "at any depth". A design like this would be backward-compatible in that existing svn:ignore properties would keep working and retain their existing meaning, and, notably, would not be deprecated. (I guess that if we introduce a new property name for ignores, that is semantically inheritable, then we would eventually deprecate the old one, because it would rarely be useful and it's easier to teach people one way of doing something than to try to explain how there are two different ways.) I also note that "The global list of ignore patterns tends to be more a matter of personal taste and ties more closely to a user's particular tool chain than to the details of any particular working copy's needs" (quoted from <http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.props.special.ignore>). That need will not go away. It is therefore not natural to carry the name "Global Ignores" into the new inheritable per-subtree ignores feature. Nor is there any need for the existing value of that configuration item to be copied verbatim into the new property, so no need (from that perspective) to keep the same syntax. I think I would find this ".../" approach more natural and understandable than having two different properties both specifying ignores. What do you think? - Julian
