On Thu, Nov 01, 2012 at 09:40:38AM -0400, Paul Burba wrote: > In case you missed it this was already discussed a little in this > thread: http://svn.haxx.se/dev/archive-2012-10/0102.shtml > > I'm mostly open to whatever the majority of folks want to call these > properties. I personally favor names that are: > > 1) Parallel the config names and describe the basic purpose, i.e. > ".*auto-props.*" and ".*ignores.*" > 2) Are not impossibly long and unwieldy > 3) Convey the fact that Subversion considers the property inheritable. > > I suspect we are all in agreement in #1 and #2, it's #3 some don't > think necessary.
I don't think #3 is necessary. We'll just get used to the fact that some properties are inheritable and others aren't. Inheritence is just one possible aspect of property-specific semantics. Consider how some props can be set only on files or directories. This is not reflected in the prop name either. Or how some properties carry mulit-line values while others do not. Some properties have boolean semantics, while others do not. > Re svn:mergeinfo, I think that's a unique case which has several > characteristics that don't necessarily set good precedents for generic > inheritable properties (e.g. can inherit from unreadable parent, only > inherits from nearest parent). If nothing else, since it predates the > inheritable property work, its naming scheme shouldn't hold much > influence over what we do going forward. That's a valid point, and you're right that we don't need to factor the history of svn:mergeinfo into this decision. Regardless of what happened in the past, I'm simply not comfortable with special-casing the naming scheme for these new properties because I don't consider inheritence something worth calling out in the prop name more than any of the other semantic aspects listed above.
