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

Re: officially freezing svn:mergeinfo syntax

From: Paul Burba <ptburba_at_gmail.com>
Date: Mon, 23 May 2011 09:45:42 -0400

On Mon, May 23, 2011 at 8:29 AM, Greg Stein <gstein_at_gmail.com> wrote:
> I've been assuming the syntax is frozen for a long time now, so yeah...
> freeze it more :-)
> On May 23, 2011 8:12 AM, "Stefan Sperling" <stsp_at_elego.de> wrote:
>> The recent fix for issue #3895 ("repos layer does not verify mergeinfo
>> syntax") implies that the syntax of svn:mergeinfo is frozen and cannot
>> be changed in future release without breaking compatibility of newer
>> clients with 1.7 servers.
>> We also backported this change to 1.6.17.
>> I am pointing this out on dev@ since it might not be obvious to those
>> who haven't reviewed the change.
>> Do people think that this might cause problems?
>> I would say it is not a problem because current clients will already
>> error out hard if the syntax is changed (see also issue #3896) so we're
>> effectively already stuck with the current syntax.

Agreed, either *potentially* break future clients with 1.6.17-1.7.x
repositories or *definitely* break existing clients exposed to invalid
mergeinfo that got into <1.6.16 repositories. We need to pick our
poison at this point and protecting existing clients against a
demonstrated problem strikes me as a better choice than worrying about
potential mergeinfo syntax changes.

FWIW I read issue #3896 to describe the problems with a client when
*invalid* mergeinfo enters the repository; though the same problems
hold for older clients if we purposefully change the syntax.

>> We can always add a new property (e.g. svn:mergeinfo2) if we want
>> to add information or use a new syntax.
>> Thoughts?

In an ideal world we would have laid the groundwork in 1.5 clients for
this, with separate mergeinfo syntax checking for repository-provided
mergeinfo vs. client/user provided/generated mergeinfo (disable merge
tracking given the former, error out given the latter). Or ever
better, the repository could have provided the syntax it supports.
Regardless, we didn't foresee the need and so we are stuck with what
we have.

Received on 2011-05-23 15:46:12 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.