[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1396184 - in /subversion/branches/auto-props-sdc/subversion: include/svn_props.h libsvn_client/add.c libsvn_client/client.h libsvn_client/commit.c tests/cmdline/autoprop_tests.py tests/cmdline/svntest/main.py

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 9 Oct 2012 16:04:41 -0400

On 10/09/2012 03:30 PM, Paul Burba wrote:
>> I don't like the term "iprop" (assuming that stands for "inheritable
>> property"), because as I understood it all properties are inheritable
>> (and it's up to the "user" of that property to decide to use it in an
>> inheritable manner or not).
>
> Sure, it's up to the user, caller, script, etc., but this is a
> reserved property that Subversion itself will always consider
> inheritable, so I don't believe "iprop" is misleading in any way.

[Just painting the bike shed.]

In retrospect, I think "svn:config-" betrays too much of the origins of the
feature. Were we designing this feature from the get-go, having *not*
already passed through lines of thought that included such phrases as
"server-dictated configuration", I doubt we'd wind up here.

I like where you're going with "iprop" -- telling the user right up front
that this sucker is inheritable. I just don't like "iprop" because it
sounds like a brand name for a line of faux Apple computers used in
furniture showrooms. Just kidding, but seriously, a new user will have no
idea what the "i" in "iprops" is for. I'd suggest just being explicit, if
verbose, and going with "svn:inheritable-auto-props" (and
"svn:inheritable-ignores", and ...).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-10-09 22:05:16 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.