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

Re: Unable to parse reversed revision range

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 01 Jul 2009 23:22:52 +0100

Paul Burba wrote:
> On Wed, Jul 1, 2009 at 9:49 AM, Paul Burba<ptburba_at_gmail.com> wrote:
> > On Wed, Jul 1, 2009 at 7:41 AM, Julian Foad<julianfoad_at_btopenworld.com> wrote:
> >> I confirm the following:
> >> [[[
> >> $ svn co -r 2575 http://qubit-toolkit.googlecode.com/svn/branches/dcb
> >> $ cd dcb
> >> $ svn merge http://qubit-toolkit.googlecode.com/svn/trunk
> >> svn: Unable to parse reversed revision range '1427-1426'
> The problem ultimately looks attributable to
> merge.c:prepare_subtree_ranges(), which is creating rangelists with
> svn_merge_range_t elements that have svn_merge_range_t.start ==
> svn_merge_range_t.end, which is a no-no:


It's great to hear that you've now been able to trace the problem and
can be more definite about why it no longer is a problem in 1.6.x.

> I suppose it's possible we could
> backport that workaround and the rest of r34016 to 1.5 except for the
> new API...but it is a not insubstantial amount of work and I have
> *zero* confidence that it would get the review and votes needed for
> backport. Getting review of far simpler merge tracking changes has
> proven a real problem and r34016 is far, far more complicated than any
> merge tracking fixes that have been backported.
> Also, searching users, it doesn't seem that this is a common problem.


> Given all of the above and barring a really compelling reason, I feel
> that the solution here is "upgrade to a 1.6 client", though I am of
> course open to arguments to the contrary.

Agreed: at that level of difficulty and that rarity, it's not worth
fixing in 1.5.x.

Thanks for the investigation.

- Julian

Received on 2009-07-02 00:23:36 CEST

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