You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by pb...@apache.org on 2012/10/31 23:56:31 UTC
svn commit: r1404404 - /subversion/site/publish/docs/release-notes/1.8.html
Author: pburba
Date: Wed Oct 31 22:56:30 2012
New Revision: 1404404
URL: http://svn.apache.org/viewvc?rev=1404404&view=rev
Log:
* site/publish/docs/release-notes/1.8.html: Complete the entry for
repository dictated configuration. A few other minor wording
and terminology tweaks.
Modified:
subversion/site/publish/docs/release-notes/1.8.html
Modified: subversion/site/publish/docs/release-notes/1.8.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.8.html?rev=1404404&r1=1404403&r2=1404404&view=diff
==============================================================================
--- subversion/site/publish/docs/release-notes/1.8.html (original)
+++ subversion/site/publish/docs/release-notes/1.8.html Wed Oct 31 22:56:30 2012
@@ -38,8 +38,8 @@ describes what is planned for the releas
>Improved support for automatic merging</a></li>
<li><a href="#iprops"
>Inherited properties</a></li>
- <li><a href="#repos-auto-ignore-props"
- >Repository dictated auto-props and ignores</a></li>
+ <li><a href="#repos-dictated-config"
+ >Repository dictated configuration</a></li>
<li><a href="#neon-deleted"
>HTTP client support based on neon has been removed</a></li>
<li><a href="#gpg-agent"
@@ -146,7 +146,7 @@ and what impact these changes may have.<
when asked for inherited properties.</td></tr>
<tr>
<tr>
- <td><a href="#repos-auto-ignore-props">Repos dictated config props</a></td>
+ <td><a href="#repos-dictated-config">Repos dictated config props</a></td>
<td>1.8</td>
<td>any</td>
<td>any</td>
@@ -503,7 +503,7 @@ Nor does this change grant access to par
have read access to. If a user has no read access to a parent path, he
cannot inherit properties from that parent.</p>
-<p>Other than the changes detailed <a href="#repos-auto-ignore-props"
+<p>Other than the changes detailed <a href="#repos-dictated-config"
>below</a>, the only user visible changes resulting from inheritable
properties is to the <tt>svn proplist</tt> and <tt>svn propget</tt>
subcommands when used with the new <tt>--show-inherited-props</tt>
@@ -565,11 +565,11 @@ This cache is updated each time you chec
copy. This cache allows the working copy to access properties inherited
from the repository without contacting the repository.</p>
-<p>For the full details about inheritable properties see this
-<a href="http://wiki.apache.org/subversion/InheritedProperties">wiki</a>.
-Some of this wiki is intended for Subversion developers and will be of
-little interest to most users. If you fall into the latter group you
-can focus on these particular sections:</p>
+<p>For the full details about inheritable properties see the
+<a href="http://wiki.apache.org/subversion/InheritedProperties"
+>design wiki</a>. Some of this wiki is intended for Subversion developers
+and will be of little interest to most users. If you fall into the latter
+group you can focus on these particular sections:</p>
<ul>
<li>
@@ -600,19 +600,68 @@ can focus on these particular sections:<
</div> <!-- iprops -->
-<div class="h3" id="repos-auto-ignore-props">
-<h3>Repository Dictated Autoprops and Ignores
- <a class="sectionlink" href="#repos-auto-ignore-props"
+<div class="h3" id="repos-dictated-config">
+<h3>Repository Dictated Configuration (<em>For auto-props and ignores</em>)
+ <a class="sectionlink" href="#repos-dictated-config"
title="Link to this section">¶</a>
</h3>
-<p>### TODO</p>
+<p>Two new Subversion reserved properties, <tt>svn:inheritable-auto-props</tt>
+and <tt>svn:inheritable-ignore</tt> make use of the new
+<a href="#iprops">inherited properties</a> feature to provide additional
+configuration information that overrides/extends some of the settings
+found in the user's <a href="http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea.opts.config"
+>runtime configuration</a>. The <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>
+
+<p>The <a href="http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Auto-Props_Format"
+>format</a> of <tt>svn:inheritable-auto-props</tt> property values
+are the same as for the <tt>auto-props</tt> runtime configuration.
+The <a href="http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Ignores_Format"
+>format</a> of <tt>svn:inheritable-ignores</tt> property values are the
+same as for the <tt>global-ignores</tt> runtime configuration.</p>
-<p>See <a href="http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps">
-this wiki</a> for more information about repository dictated autoprops
-and ignores.</p>
+<p>Both properties work just like their analogs in the runtime
+configuration with two exceptions:</p>
-</div> <!-- repos-auto-ignore-props -->
+<ul>
+ <li>The new properties only effect the subtrees rooted at the path
+ on which the property is set. Thus a given path may be affected
+ by multiple <tt>svn:inheritable-*</tt> properties set on different
+ parents of that path.</li>
+ <li>Unlike the <tt>auto-props</tt> and <TT>global-ignores</tt> runtime
+ configurations, and <tt>svn:ignores</tt>, all of which can be
+ disabled in the runtime config or via command line options, these
+ new inheritable configuration properties <b>cannot</b> be
+ disregarded by a standard 1.8 client. Of course, given the
+ existence of older clients which do not understand the new
+ properties and the ease with which a custom client can be created
+ that ignores the new properties, repository administrators should
+ still set up server-side enforcement of desired behaviors via hook
+ scripts.</li>
+</ul>
+
+<p>When multiple <tt>svn:inheritable-ignores</tt> properties apply to a
+path, then the different values are appended to any runtime
+<tt>global-ignores</tt> in effect and the value of any <tt>svn:ignore</tt>
+property that applies to the path.</p>
+
+<p>Patterns defined in <tt>svn:inheritable-auto-props</tt> property
+override any identical patterns in the <tt>auto-props</tt> runtime
+config. When multiple <tt>svn:inheritable-auto-props</tt> properties
+apply to a file, the pattern from the nearest inheritable property takes
+precedence. See <a href="http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Auto-Props_Hierarchy_and_Precedence"
+>this section of design wiki</a> for a full explanation.</p>
+
+<p>The <a href="http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps#Auto-Props_Hierarchy_and_Precedence"
+>design wiki</a> for the repository dictated configuration feature was
+originally written for developers, but will prove useful to any repository
+administrator who wants to use the feature.</p>
+
+</div> <!-- repos-dictated-config -->
<div class="h3" id="gpg-agent">
<h3>In-memory password caching via GnuPG (<em>Unix client</em>)
Re: inheritable properties names (was: Re: svn commit: r1404404 -
/subversion/site/publish/docs/release-notes/1.8.html)
Posted by Stefan Sperling <st...@elego.de>.
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.
Re: inheritable properties names (was: Re: svn commit: r1404404 - /subversion/site/publish/docs/release-notes/1.8.html)
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Nov 1, 2012 at 7:08 AM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Oct 31, 2012 at 10:56:31PM -0000, pburba@apache.org wrote:
>> Author: pburba
>> Date: Wed Oct 31 22:56:30 2012
>> New Revision: 1404404
>>
>> URL: http://svn.apache.org/viewvc?rev=1404404&view=rev
>> Log:
>> * site/publish/docs/release-notes/1.8.html: Complete the entry for
>> repository dictated configuration. A few other minor wording
>> and terminology tweaks.
>
>> +<p>Two new Subversion reserved properties, <tt>svn:inheritable-auto-props</tt>
>> +and <tt>svn:inheritable-ignore</tt> make use of the new
>> +<a href="#iprops">inherited properties</a> feature to provide additional
>> +configuration information that overrides/extends some of the settings
>> +found in the user's <a href="http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea.opts.config"
>> +>runtime configuration</a>. The <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?
Hi Stefan,
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.
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.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: inheritable properties names
Posted by Branko Čibej <br...@wandisco.com>.
On 05.11.2012 15:19, Paul Burba wrote:
> On Thu, Nov 1, 2012 at 10:59 AM, Stefan Sperling <st...@elego.de> wrote:
>> On Thu, Nov 01, 2012 at 10:40:41AM -0400, Mark Phippard wrote:
>>> Guess I just do not see big benefit from using the existing property.
>>> I am not vetoing the idea or anything, just do not see the big
>>> improvement and the parsing/merging sounds complicated.
>> I agree. Changing the way svn:ignore works introduces a risk
>> of regressions without much benefit.
> It probably goes without saying, but I'm with Mark and Stefan on this.
> I don't see any advantage to piggybacking new inheritable ignore
> behavior on the existing svn:ignore property.
>
> As for the property names, after much discussion on IRC
> (http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-11-01#l185)
> it appears we are in agreement on these changes:
>
> "svn:inheritable-auto-props" --> "svn:auto-props".
> "svn:inheritable-ignores" --> "svn:global-ignores"
+1 from the peanut gallery.
-- Brane
Re: inheritable properties names (was: Re: svn commit: r1404404 - /subversion/site/publish/docs/release-notes/1.8.html)
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Mon, Nov 5, 2012 at 6:19 PM, Paul Burba <pt...@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 10:59 AM, Stefan Sperling <st...@elego.de> wrote:
>> On Thu, Nov 01, 2012 at 10:40:41AM -0400, Mark Phippard wrote:
>>> Guess I just do not see big benefit from using the existing property.
>>> I am not vetoing the idea or anything, just do not see the big
>>> improvement and the parsing/merging sounds complicated.
>>
>> I agree. Changing the way svn:ignore works introduces a risk
>> of regressions without much benefit.
>
> It probably goes without saying, but I'm with Mark and Stefan on this.
> I don't see any advantage to piggybacking new inheritable ignore
> behavior on the existing svn:ignore property.
>
> As for the property names, after much discussion on IRC
> (http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-11-01#l185)
> it appears we are in agreement on these changes:
>
> "svn:inheritable-auto-props" --> "svn:auto-props".
> "svn:inheritable-ignores" --> "svn:global-ignores"
>
> (Yes, the "global" in svn:global-ignores is only "global" to the
> subtree on which the property is set, but we want to differentiate
> between the old "svn:ignore" property and as Stefan pointed out in
> IRC, we just need to pick a name, document the behavior and go with
> it)
>
+1.
--
Ivan Zhakov
Re: inheritable properties names (was: Re: svn commit: r1404404 - /subversion/site/publish/docs/release-notes/1.8.html)
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Nov 1, 2012 at 10:59 AM, Stefan Sperling <st...@elego.de> wrote:
> On Thu, Nov 01, 2012 at 10:40:41AM -0400, Mark Phippard wrote:
>> Guess I just do not see big benefit from using the existing property.
>> I am not vetoing the idea or anything, just do not see the big
>> improvement and the parsing/merging sounds complicated.
>
> I agree. Changing the way svn:ignore works introduces a risk
> of regressions without much benefit.
It probably goes without saying, but I'm with Mark and Stefan on this.
I don't see any advantage to piggybacking new inheritable ignore
behavior on the existing svn:ignore property.
As for the property names, after much discussion on IRC
(http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-11-01#l185)
it appears we are in agreement on these changes:
"svn:inheritable-auto-props" --> "svn:auto-props".
"svn:inheritable-ignores" --> "svn:global-ignores"
(Yes, the "global" in svn:global-ignores is only "global" to the
subtree on which the property is set, but we want to differentiate
between the old "svn:ignore" property and as Stefan pointed out in
IRC, we just need to pick a name, document the behavior and go with
it)
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: inheritable properties names (was: Re: svn commit: r1404404 -
/subversion/site/publish/docs/release-notes/1.8.html)
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 01, 2012 at 10:40:41AM -0400, Mark Phippard wrote:
> Guess I just do not see big benefit from using the existing property.
> I am not vetoing the idea or anything, just do not see the big
> improvement and the parsing/merging sounds complicated.
I agree. Changing the way svn:ignore works introduces a risk
of regressions without much benefit.
Re: inheritable properties names (was: Re: svn commit: r1404404 - /subversion/site/publish/docs/release-notes/1.8.html)
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Nov 1, 2012 at 10:30 AM, Julian Foad <ju...@btopenworld.com> wrote:
> I'm not sure what you're saying here. The new client-side API [1] for retrieving a given property name will return a list of all the
> values set on the various parents, and it's then up to the caller to decide how to merge them.
Yes, agreed. Paul's implementation merges the values. I guess in the
case of ignore it is just a simple merge, but in the case of the
auto-props it has to give precedence to the closer property.
So I am just saying the merge becomes weirder. I guess for any
property it finds from inherited parent folders it would have to parse
the value and look for the items that were the special syntax, and
only merge those value into the values that are found in the immediate
parent. That is assuming that syntax you propose works with current
and old clients. (Never seen it used before).
>> I like the idea of a new property for this.
>
> Why?
Maybe just because that is how I have thought about it from the start.
I do not see any great value in changing what the existing property
can do. I assume that with your special syntax older SVN clients
would not be impacted because they would process it correctly based on
the old behavior? We have to hope and assume GUI Clients gracefully
handle it as well, which they probably do.
Guess I just do not see big benefit from using the existing property.
I am not vetoing the idea or anything, just do not see the big
improvement and the parsing/merging sounds complicated.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: inheritable properties names (was: Re: svn commit: r1404404 - /subversion/site/publish/docs/release-notes/1.8.html)
Posted by Julian Foad <ju...@btopenworld.com>.
Mark Phippard wrote:
> Julian Foad wrote:
>> 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'm not sure what you're saying here. The new client-side API [1] for retrieving a given property name will return a list of all the values set on the various parents, and it's then up to the caller to decide how to merge them.
[1] <http://wiki.apache.org/subversion/InheritedProperties#API_Changes>
> 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.
Do it like this:
inh_ignores = get_property(path, "svn:ignore", include_inherited=True)
# inh_ignores is a mapping from "path-on-which-it's-set" to "pattern-list".
sort inh_ignores by "path-on-which-it's-set", in root-to-leaf order.
final_ignore_patterns = (an empty set)
for each pattern-list in inh_ignores:
for each pattern in pattern-list:
final_ignore_patterns.add_or_replace(pattern)
> I like the idea of a new property for this.
Why?
- Julian
Re: inheritable properties names (was: Re: svn commit: r1404404 - /subversion/site/publish/docs/release-notes/1.8.html)
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Nov 1, 2012 at 10:00 AM, Julian Foad <ju...@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/
Re: inheritable properties names (was: Re: svn commit: r1404404 - /subversion/site/publish/docs/release-notes/1.8.html)
Posted by Julian Foad <ju...@btopenworld.com>.
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
inheritable properties names (was: Re: svn commit: r1404404 -
/subversion/site/publish/docs/release-notes/1.8.html)
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Oct 31, 2012 at 10:56:31PM -0000, pburba@apache.org wrote:
> Author: pburba
> Date: Wed Oct 31 22:56:30 2012
> New Revision: 1404404
>
> URL: http://svn.apache.org/viewvc?rev=1404404&view=rev
> Log:
> * site/publish/docs/release-notes/1.8.html: Complete the entry for
> repository dictated configuration. A few other minor wording
> and terminology tweaks.
> +<p>Two new Subversion reserved properties, <tt>svn:inheritable-auto-props</tt>
> +and <tt>svn:inheritable-ignore</tt> make use of the new
> +<a href="#iprops">inherited properties</a> feature to provide additional
> +configuration information that overrides/extends some of the settings
> +found in the user's <a href="http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.confarea.opts.config"
> +>runtime configuration</a>. The <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?