You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2012/11/01 12:08:15 UTC
inheritable properties names (was: Re: svn commit: r1404404 -
/subversion/site/publish/docs/release-notes/1.8.html)
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?
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