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.
Received on 2012-11-01 15:35:53 CET