You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2009/02/25 16:42:14 UTC
Re: Unable to parse reversed revision range
On Wed, Jan 28, 2009 at 3:58 PM, Brian Rieck <BR...@sandcherry.com> wrote:
> For efficiency reasons, the system has converted the large body of this message into an attachment.
>
> ---------- Forwarded message ----------
> From: "Brian Rieck" <BR...@sandcherry.com>
> To: "Paul Burba" <pt...@gmail.com>
> Date: Wed, 28 Jan 2009 13:57:36 -0700
> Subject: RE: Re: Unable to parse reversed revision range
> 1) Is this right? Where is the path separator?
>
> I do not believe this is correct output. I believe that the path separator was stripped somehow in my cut and paste. I see the path separator in the file where I redirected output.
>
> 2) Could you provide the exact command and output of this successful
> merge to 'platform\packagingdistribution\Vivo
> Applications\vmc\WebContent'?
>
> Just for fun I created another branch to do this in.
>
> 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?
What about http://svn-backup/sc/SVP/branches/user_branches/jeff4?
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
Re: Unable to parse reversed revision range
Posted by Julian Foad <ju...@btopenworld.com>.
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 Paul Burba <pt...@gmail.com>.
A quick update:
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 (yes, yes, this should be simple...it
is not).
For anyone hitting this problem your best bet is to upgrade you client
to 1.6.0 when that is released (it *should* be released this month).
I'll still try to get the correct fix backported to 1.5.7, but barring
some sort of cataclysm that will not be released till well after
1.6.0.
Paul
On Wed, Feb 25, 2009 at 12:00 PM, Brian Rieck <BR...@sandcherry.com> wrote:
>
>
> -----Original Message-----
> From: Paul Burba [mailto:ptburba@gmail.com]
> Sent: Wednesday, February 25, 2009 9:42 AM
> To: Brian Rieck
> Cc: dev@subversion.tigris.org
> Subject: Re: Unable to parse reversed revision range
>
> On Wed, Jan 28, 2009 at 3:58 PM, Brian Rieck <BR...@sandcherry.com> wrote:
>> For efficiency reasons, the system has converted the large body of this message into an attachment.
>>
>> ---------- Forwarded message ----------
>> From: "Brian Rieck" <BR...@sandcherry.com>
>> To: "Paul Burba" <pt...@gmail.com>
>> Date: Wed, 28 Jan 2009 13:57:36 -0700
>> Subject: RE: Re: Unable to parse reversed revision range
>> 1) Is this right? Where is the path separator?
>>
>> I do not believe this is correct output. I believe that the path separator was stripped somehow in my cut and paste. I see the path separator in the file where I redirected output.
>>
>> 2) Could you provide the exact command and output of this successful
>> merge to 'platform\packagingdistribution\Vivo
>> Applications\vmc\WebContent'?
>>
>> Just for fun I created another branch to do this in.
>>
>> 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
RE: Unable to parse reversed revision range
Posted by Brian Rieck <BR...@sandcherry.com>.
-----Original Message-----
From: Paul Burba [mailto:ptburba@gmail.com]
Sent: Wednesday, February 25, 2009 9:42 AM
To: Brian Rieck
Cc: dev@subversion.tigris.org
Subject: Re: Unable to parse reversed revision range
On Wed, Jan 28, 2009 at 3:58 PM, Brian Rieck <BR...@sandcherry.com> wrote:
> For efficiency reasons, the system has converted the large body of this message into an attachment.
>
> ---------- Forwarded message ----------
> From: "Brian Rieck" <BR...@sandcherry.com>
> To: "Paul Burba" <pt...@gmail.com>
> Date: Wed, 28 Jan 2009 13:57:36 -0700
> Subject: RE: Re: Unable to parse reversed revision range
> 1) Is this right? Where is the path separator?
>
> I do not believe this is correct output. I believe that the path separator was stripped somehow in my cut and paste. I see the path separator in the file where I redirected output.
>
> 2) Could you provide the exact command and output of this successful
> merge to 'platform\packagingdistribution\Vivo
> Applications\vmc\WebContent'?
>
> Just for fun I created another branch to do this in.
>
> 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.