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

Re: inheritable properties names (was: Re: svn commit: r1404404 - /subversion/site/publish/docs/release-notes/1.8.html)

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 1 Nov 2012 10:40:41 -0400

On Thu, Nov 1, 2012 at 10:30 AM, Julian Foad <julianfoad_at_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.

Mark Phippard
Received on 2012-11-01 15:41:16 CET

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