You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2009/06/30 22:51:30 UTC
Re: Unable to parse reversed revision range
On Mon, 2009-03-02 at 16:34 -0500, Paul Burba wrote:
> I have been unable to replicate this problem, but with Brian's help
> have determined that it doesn't exist in 1.6.0 Release Candidate 3
> (and presumably trunk). The error still occurs with 1.5.7 Dev
> however. I am still trying to figure out what needs to be backported
> from trunk to 1.5.x to fix this [...]
Hi Paul and others. I am looking at this problem for a client.
Obviously upgrading to 1.6.x will be a recommended fix. In case
upgrading is not a good solution for some other reason, I'd be
interested to know if (a) you were ever able to reproduce this and (b)
if there is any identified cause or fix.
- Julian
> On Wed, Feb 25, 2009 at 12:00 PM, Brian Rieck <BR...@sandcherry.com> wrote:
> > -----Original Message-----
> > From: Paul Burba [mailto:ptburba@gmail.com]
[...]
> >> Output of attempt to merge entire tree:
> >> ************
> >> D:\svp_backup>svn merge http://svn-backup/sc/SVP/branches/user_branches/camille
> >> .\jeff4
> >> svn: Unable to parse reversed revision range '3-2'
> >> *************
> >
> > Hi Brian,
> >
> > What is the history of
> > http://svn-backup/sc/SVP/branches/user_branches/camille? Was it
> > copied directly from trunk or from some other branch?
> >
> > It was copied from a branch named "4.1.00_Dev" which was copied from trunk. This branch was created by me on the test server as a way to reproduce the problem being seen on the "real" server.
> >
> > What about http://svn-backup/sc/SVP/branches/user_branches/jeff4?
> >
> > This was copied from the "camille" branch.
> >
> > From the mergeinfo dump of the repository you provided I see that
> > there is no mergeinfo on or under trunk, and only empty mergeinfo
> > within the trees rooted at camille and jeff4. But there are other
> > branches, e.g.
> >
> > http://svn-backup/sc/SVP/branches/user_branches/cwall_vmc_090109/platform/packaging/distribution/Vivo
> > Applications/vmc/WebContent/pages/profilesVocab/updateVocab.xhtml -
> > /trunk/platform/packaging/distribution/Vivo
> > Applications/vmc/WebContent/pages/profilesVocab/updateVocab.xhtml:2
> >
> > that do have explicit mergeinfo and are under the 'problem' directory
> > of '/platform/packaging/distribution/Vivo'...not a coincidence I
> > suspect, but I still haven't put together a reproduction.
> >
> > Interesting that you would mention the "cwall_vmc_090109" branch. That is the branch in the "real" repo that is the equivalent of the "Camille" branch I created in the test server. (The test server repo was a restore of a backup of the "real" server.)
> >
> >
> >
> >> Output of just merging the "problem" directory:
> >> *************
> >> D:\svp_backup>svn merge "http://svn-backup/sc/SVP/branches/user_branches/camille
> >> /platform/packaging/distribution/Vivo Applications/vmc/WebContent" ".\jeff4\plat
> >> form\packaging\distribution\Vivo Applications\vmc\WebContent"
> >> *************
> >>
> >> Second attempt to merge entire tree:
> >> *************
> >> D:\svp_backup>svn merge http://svn-backup/sc/SVP/branches/user_branches/camille
> >> .\jeff4
> >>
> >> D:\svp_backup>
> >> ***************
> >>
> >>
> >> 3) What version of svn do your users use?
> >>
> >> They are using 1.5.4. I plan on upgrading to 1.5.5 this week. Should I expect these problems to go away even on branches created with 1.5.4, or should I still see those problems with the "old" branches?
> >
> > The issue #3067 related problems should go away with 1.5.5 yes, there
> > are no know issues with that anymore. If you still see this with
> > 1.5.5 let me know, but start another thread.
> >
> > Paul
> >
> >> 4) Using svn <= 1.5.5 could you run 'svn pg svn:mergeinfo -R' on the root
> >> of the repository prior to '7) svn merge <url_to_new_camille_branch>
> >> <wc_path_to_jeff3>'?
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1258370
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2366869
Re: Unable to parse reversed revision range
Posted by Julian Foad <ju...@btopenworld.com>.
Paul Burba wrote:
> On Wed, Jul 1, 2009 at 9:49 AM, Paul Burba<pt...@gmail.com> wrote:
> > On Wed, Jul 1, 2009 at 7:41 AM, Julian Foad<ju...@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:
Paul,
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.
Agreed.
> 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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2367206
Re: Unable to parse reversed revision range
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Jul 1, 2009 at 9:49 AM, Paul Burba<pt...@gmail.com> wrote:
> On Wed, Jul 1, 2009 at 7:41 AM, Julian Foad<ju...@btopenworld.com> wrote:
>> I (Julian Foad) wrote:
>>> On Mon, 2009-03-02 at 16:34 -0500, Paul Burba wrote:
>>> > I have been unable to replicate this problem, but with Brian's help
>>> > have determined that it doesn't exist in 1.6.0 Release Candidate 3
>>> > (and presumably trunk). The error still occurs with 1.5.7 Dev
>>> > however. I am still trying to figure out what needs to be backported
>>> > from trunk to 1.5.x to fix this [...]
>>>
>>> Hi Paul and others. I am looking at this problem for a client.
>>>
>>> Obviously upgrading to 1.6.x will be a recommended fix. In case
>>> upgrading is not a good solution for some other reason, I'd be
>>> interested to know if (a) you were ever able to reproduce this and (b)
>>> if there is any identified cause or fix.
>>
>> I am able to reproduce the problem with a 1.5.x client
>> (^/branches/1.5.x/@38201) by using the recipe at
>> <http://groups.google.com/group/google-code-hosting/browse_thread/thread/47ef0b9691e2af8e>.
>>
>> Some significant revisions of that repository are:
>>
>> ------------------------------------------------------------------------
>> r1 | jablko | 2007-10-03 19:55:01 +0100 (Wed, 03 Oct 2007) | 2 lines
>> Changed paths:
>> A /branches
>> A /tags
>> A /trunk
>>
>> Create default structure.
>>
>> ------------------------------------------------------------------------
>> r1426 | jablko | 2008-10-02 17:50:57 +0100 (Thu, 02 Oct 2008) | 3 lines
>> Changed paths:
>> A /qubit (from /trunk:1425)
>> D /trunk
>>
>> First step in vendor branches repository reorganization: Rename trunk to
>> make room for new parent trunk directory.
>> http://qubit-toolkit.org/wiki/index.php?title=Vendor_branches
>>
>> ------------------------------------------------------------------------
>> r1427 | jablko | 2008-10-02 18:32:35 +0100 (Thu, 02 Oct 2008) | 6 lines
>> Changed paths:
>> D /qubit
>> A /trunk
>> A /trunk/qubit (from /qubit:1426)
>>
>> M /trunk/qubit/lib/vendor
>> A /trunk/qubit/lib/vendor/symfony
>> A /trunk/qubit/lib/vendor/symfony/CHANGELOG
>> A /trunk/qubit/lib/vendor/[...]
>> A /trunk/qubit/lib/vendor/symfony/test/unit/yaml/sfYamlParserTest.php
>>
>> D /trunk/qubit/patches/component-class-name.patch
>> D /trunk/qubit/patches/[...]
>> D /trunk/qubit/patches/yaml-inline.patch
>>
>> A /trunk/symfony
>> A /trunk/symfony/vendor
>> A /trunk/symfony/vendor/CHANGELOG
>> A /trunk/symfony/vendor/[...]
>> A /trunk/symfony/vendor/test/unit/yaml/sfYamlParserTest.php
>>
>> Finish vendor branches repository reorganization:
>> Add new parent trunk directory and make qubit and symfony its children.
>> Initial symfony vendor drop from:
>> http://svn.symfony-project.com/branches/1.1
>> Remove symfony Subversion externals property and copy symfony vendor
>> branch to qubit.
>> Apply patches to qubit symfony branch and remove the obsolete patches.
>>
>> ------------------------------------------------------------------------
>> r2414 | jablko | 2009-04-25 06:03:59 +0100 (Sat, 25 Apr 2009) | 2 lines
>> Changed paths:
>> A /PHP_CodeSniffer (from /trunk/PHP_CodeSniffer:2413)
>> A /drupal (from /trunk/drupal:2413)
>> A /qubit (from /trunk/qubit:2413)
>> A /sfThumbnailPlugin (from /trunk/sfThumbnailPlugin:2413)
>> A /symfony (from /trunk/symfony:2413)
>> D /trunk
>> A /yui (from /trunk/yui:2413)
>>
>> First step in repository reorganization, move children of trunk to root
>> and delete trunk
>>
>> ------------------------------------------------------------------------
>> r2415 | jablko | 2009-04-25 06:33:27 +0100 (Sat, 25 Apr 2009) | 2 lines
>> Changed paths:
>> D /qubit
>> A /trunk (from /qubit:2414)
>>
>> Finish repository reorganization
>>
>> ------------------------------------------------------------------------
>> r2550 | jablko | 2009-05-13 17:42:21 +0100 (Wed, 13 May 2009) | 2 lines
>> Changed paths:
>> A /branches/dcb (from /trunk:2549)
>>
>> Create Digital Collection Builder branch
>>
>> ------------------------------------------------------------------------
>>
>>
>> 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'
>> ]]]
>>
>> I have written the attached test script to try to mimic this series of
>> events but I have missed something because the test script doesn't fail.
>>
>> - Julian
>
> Hi Julian,
>
> Wow, this brings back some bad memories :-)
>
> Despite an immense amount of off-list cooperation from Brian I was
> never able to replicate this on 1.5, so was never able to pinpoint the
> fix(es) to be backported. With the googlecode example though I should
> now be able to figure it out now. I'll take a look today.
>
> Paul
Hey Julian,
Well that was awful, but at least I finally have something to debug!
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:
/**
* Mergeinfo representing a merge of a range of revisions.
*
* @since New in 1.5
*/
typedef struct svn_merge_range_t
{
/* If the 'start' field is less than the 'end' field then 'start' is
* exclusive and 'end' inclusive of the range described. If 'start'
* is greater than 'end' then the opposite is true. If 'start'
* equals 'end' the meaning of the range is not defined.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*/
svn_revnum_t start;
svn_revnum_t end;
/* Whether this merge range should be inherited by treewise
descendants of the path to which the range applies. */
svn_boolean_t inheritable;
} svn_merge_range_t;
As mentioned earlier in this thread, this problem does not exist in
1.6 (again, all that is needed is the 1.6 client). Turns out this is
due to a substantial reworking of this code I did to address issue
#3067 (see r34016 and the issue-3067-deleted-subtrees branch).
r34016 introduced a new API svn_ra_get_deleted_rev, though it has a
Subversion private work-around svn_ra__get_deleted_rev_from_log() for
dealing with pre 1.6 servers. 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.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2367189
Re: Unable to parse reversed revision range
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Jul 1, 2009 at 7:41 AM, Julian Foad<ju...@btopenworld.com> wrote:
> I (Julian Foad) wrote:
>> On Mon, 2009-03-02 at 16:34 -0500, Paul Burba wrote:
>> > I have been unable to replicate this problem, but with Brian's help
>> > have determined that it doesn't exist in 1.6.0 Release Candidate 3
>> > (and presumably trunk). The error still occurs with 1.5.7 Dev
>> > however. I am still trying to figure out what needs to be backported
>> > from trunk to 1.5.x to fix this [...]
>>
>> Hi Paul and others. I am looking at this problem for a client.
>>
>> Obviously upgrading to 1.6.x will be a recommended fix. In case
>> upgrading is not a good solution for some other reason, I'd be
>> interested to know if (a) you were ever able to reproduce this and (b)
>> if there is any identified cause or fix.
>
> I am able to reproduce the problem with a 1.5.x client
> (^/branches/1.5.x/@38201) by using the recipe at
> <http://groups.google.com/group/google-code-hosting/browse_thread/thread/47ef0b9691e2af8e>.
>
> Some significant revisions of that repository are:
>
> ------------------------------------------------------------------------
> r1 | jablko | 2007-10-03 19:55:01 +0100 (Wed, 03 Oct 2007) | 2 lines
> Changed paths:
> A /branches
> A /tags
> A /trunk
>
> Create default structure.
>
> ------------------------------------------------------------------------
> r1426 | jablko | 2008-10-02 17:50:57 +0100 (Thu, 02 Oct 2008) | 3 lines
> Changed paths:
> A /qubit (from /trunk:1425)
> D /trunk
>
> First step in vendor branches repository reorganization: Rename trunk to
> make room for new parent trunk directory.
> http://qubit-toolkit.org/wiki/index.php?title=Vendor_branches
>
> ------------------------------------------------------------------------
> r1427 | jablko | 2008-10-02 18:32:35 +0100 (Thu, 02 Oct 2008) | 6 lines
> Changed paths:
> D /qubit
> A /trunk
> A /trunk/qubit (from /qubit:1426)
>
> M /trunk/qubit/lib/vendor
> A /trunk/qubit/lib/vendor/symfony
> A /trunk/qubit/lib/vendor/symfony/CHANGELOG
> A /trunk/qubit/lib/vendor/[...]
> A /trunk/qubit/lib/vendor/symfony/test/unit/yaml/sfYamlParserTest.php
>
> D /trunk/qubit/patches/component-class-name.patch
> D /trunk/qubit/patches/[...]
> D /trunk/qubit/patches/yaml-inline.patch
>
> A /trunk/symfony
> A /trunk/symfony/vendor
> A /trunk/symfony/vendor/CHANGELOG
> A /trunk/symfony/vendor/[...]
> A /trunk/symfony/vendor/test/unit/yaml/sfYamlParserTest.php
>
> Finish vendor branches repository reorganization:
> Add new parent trunk directory and make qubit and symfony its children.
> Initial symfony vendor drop from:
> http://svn.symfony-project.com/branches/1.1
> Remove symfony Subversion externals property and copy symfony vendor
> branch to qubit.
> Apply patches to qubit symfony branch and remove the obsolete patches.
>
> ------------------------------------------------------------------------
> r2414 | jablko | 2009-04-25 06:03:59 +0100 (Sat, 25 Apr 2009) | 2 lines
> Changed paths:
> A /PHP_CodeSniffer (from /trunk/PHP_CodeSniffer:2413)
> A /drupal (from /trunk/drupal:2413)
> A /qubit (from /trunk/qubit:2413)
> A /sfThumbnailPlugin (from /trunk/sfThumbnailPlugin:2413)
> A /symfony (from /trunk/symfony:2413)
> D /trunk
> A /yui (from /trunk/yui:2413)
>
> First step in repository reorganization, move children of trunk to root
> and delete trunk
>
> ------------------------------------------------------------------------
> r2415 | jablko | 2009-04-25 06:33:27 +0100 (Sat, 25 Apr 2009) | 2 lines
> Changed paths:
> D /qubit
> A /trunk (from /qubit:2414)
>
> Finish repository reorganization
>
> ------------------------------------------------------------------------
> r2550 | jablko | 2009-05-13 17:42:21 +0100 (Wed, 13 May 2009) | 2 lines
> Changed paths:
> A /branches/dcb (from /trunk:2549)
>
> Create Digital Collection Builder branch
>
> ------------------------------------------------------------------------
>
>
> 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'
> ]]]
>
> I have written the attached test script to try to mimic this series of
> events but I have missed something because the test script doesn't fail.
>
> - Julian
Hi Julian,
Wow, this brings back some bad memories :-)
Despite an immense amount of off-list cooperation from Brian I was
never able to replicate this on 1.5, so was never able to pinpoint the
fix(es) to be backported. With the googlecode example though I should
now be able to figure it out now. I'll take a look today.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2367050
Re: Unable to parse reversed revision range
Posted by Julian Foad <ju...@btopenworld.com>.
I (Julian Foad) wrote:
> On Mon, 2009-03-02 at 16:34 -0500, Paul Burba wrote:
> > I have been unable to replicate this problem, but with Brian's help
> > have determined that it doesn't exist in 1.6.0 Release Candidate 3
> > (and presumably trunk). The error still occurs with 1.5.7 Dev
> > however. I am still trying to figure out what needs to be backported
> > from trunk to 1.5.x to fix this [...]
>
> Hi Paul and others. I am looking at this problem for a client.
>
> Obviously upgrading to 1.6.x will be a recommended fix. In case
> upgrading is not a good solution for some other reason, I'd be
> interested to know if (a) you were ever able to reproduce this and (b)
> if there is any identified cause or fix.
I am able to reproduce the problem with a 1.5.x client
(^/branches/1.5.x/@38201) by using the recipe at
<http://groups.google.com/group/google-code-hosting/browse_thread/thread/47ef0b9691e2af8e>.
Some significant revisions of that repository are:
------------------------------------------------------------------------
r1 | jablko | 2007-10-03 19:55:01 +0100 (Wed, 03 Oct 2007) | 2 lines
Changed paths:
A /branches
A /tags
A /trunk
Create default structure.
------------------------------------------------------------------------
r1426 | jablko | 2008-10-02 17:50:57 +0100 (Thu, 02 Oct 2008) | 3 lines
Changed paths:
A /qubit (from /trunk:1425)
D /trunk
First step in vendor branches repository reorganization: Rename trunk to
make room for new parent trunk directory.
http://qubit-toolkit.org/wiki/index.php?title=Vendor_branches
------------------------------------------------------------------------
r1427 | jablko | 2008-10-02 18:32:35 +0100 (Thu, 02 Oct 2008) | 6 lines
Changed paths:
D /qubit
A /trunk
A /trunk/qubit (from /qubit:1426)
M /trunk/qubit/lib/vendor
A /trunk/qubit/lib/vendor/symfony
A /trunk/qubit/lib/vendor/symfony/CHANGELOG
A /trunk/qubit/lib/vendor/[...]
A /trunk/qubit/lib/vendor/symfony/test/unit/yaml/sfYamlParserTest.php
D /trunk/qubit/patches/component-class-name.patch
D /trunk/qubit/patches/[...]
D /trunk/qubit/patches/yaml-inline.patch
A /trunk/symfony
A /trunk/symfony/vendor
A /trunk/symfony/vendor/CHANGELOG
A /trunk/symfony/vendor/[...]
A /trunk/symfony/vendor/test/unit/yaml/sfYamlParserTest.php
Finish vendor branches repository reorganization:
Add new parent trunk directory and make qubit and symfony its children.
Initial symfony vendor drop from:
http://svn.symfony-project.com/branches/1.1
Remove symfony Subversion externals property and copy symfony vendor
branch to qubit.
Apply patches to qubit symfony branch and remove the obsolete patches.
------------------------------------------------------------------------
r2414 | jablko | 2009-04-25 06:03:59 +0100 (Sat, 25 Apr 2009) | 2 lines
Changed paths:
A /PHP_CodeSniffer (from /trunk/PHP_CodeSniffer:2413)
A /drupal (from /trunk/drupal:2413)
A /qubit (from /trunk/qubit:2413)
A /sfThumbnailPlugin (from /trunk/sfThumbnailPlugin:2413)
A /symfony (from /trunk/symfony:2413)
D /trunk
A /yui (from /trunk/yui:2413)
First step in repository reorganization, move children of trunk to root
and delete trunk
------------------------------------------------------------------------
r2415 | jablko | 2009-04-25 06:33:27 +0100 (Sat, 25 Apr 2009) | 2 lines
Changed paths:
D /qubit
A /trunk (from /qubit:2414)
Finish repository reorganization
------------------------------------------------------------------------
r2550 | jablko | 2009-05-13 17:42:21 +0100 (Wed, 13 May 2009) | 2 lines
Changed paths:
A /branches/dcb (from /trunk:2549)
Create Digital Collection Builder branch
------------------------------------------------------------------------
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'
]]]
I have written the attached test script to try to mimic this series of
events but I have missed something because the test script doesn't fail.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2367009