RE: Re: Unable to parse reversed revision range

Thanks Paul,

I get no output from the svn propget svn:mergeinfo for any of those urls.

Yes, actually the no-op was intentional but it produced the error. I was trying to reproduce the problem that a user was seeing on the production server and had a list of things that he thought he had done, all of which looked benign to me. I wanted to try a merge after each possibility to see what might reproduce the problem. I was surprised to see it happen right away; I fully expected a no-op.

Wow, the 'svn log -vq' command, even on one file was huge! I guess it contains info about all the files committees at the same time for each rev. This will include 50,000+ files for the intial import though. Parsing it was looking pretty tough. I was able though with just a "normal" log command to find the revision where a file was moved from one location to another. I then did the diff as requested and did see:

Added: svn:mergeinfo

Yep, I can successfully do a merge at any level other than the root all the way doen to the problem directory. Here is some info from my original long winded post:

*******************

I have isolated the problem to a specific directory fairly deep in the tree. Interestingly enough if I do a merge of just that directory or *any of its parents except* the very top level of the tree it works. After doing that merge I can then successfully merge the entire tree.

I get no output from the “svn propget svn:mergeinfo” command on the problem directory in either branch. (I tried verbose as suggested but propget doesn’t seem to allow for a verbose flag)

The diff of the problem directory after merging just the problem directory (which seems to solve the problem):

******************************
Property changes on: platform\packaging​​distribution\Vivo Applications\vmc\WebContent
____________________​​___________________​_​__________________​__​_______
Modified: svn:mergeinfo
   Merged /branches/4.1.00_Dev​​/platform/packaging​/​distribution/Vivo Applications/vmc/Web​​Content:r3-373
   Merged /branches/user_branc​​hes/camille/platfor​m​/packaging/distrib​ut​ion/Vivo Applications/vmc/Web​​Content:r704

******************************

btw - This is probably unrelated but I am also receiving a fair number of complaints about "Working copy path "<path> "does not exist in repository" errors while merging and "Working copy" <path> "locked" errors while people are trying to merge from parent to child branches. I think the Working copy locked" problem was because of a move that did nothing but change the case of a folder name. We seem to have been able to work around these problems through a combination of deleting working copies before merging. I have been assuming that these problems are unrelated to the one at hand but thought I'd bring it up.

Since this is a test server I can do anything to it without ramifications, including blowing away the repo and bringing it back from a backup of the production repo. So if there is anything you want me to do at all I can do it. If you would like I can redo my steps but capture the output to a file. You would probably want me to either surpress the initial co output as it will be long. Just let me know. If I do that would it be acceptable to include it as an attachment or would it be preferred on the mailing list to include the output in the mail message?

I really appreciate your help.

-Brian

-----Original Message-----
From: Paul Burba [mailto:ptburba_at_gmail.com]
Sent: Monday, January 26, 2009 3:35 PM
To: Brian Rieck
Cc: dev_at_subversion.tigris.org
Subject: Re: Re: Unable to parse reversed revision range

On Mon, Jan 26, 2009 at 4:21 PM, Brian Rieck <BRieck_at_sandcherry.com> wrote:
> Thanks for the quick reply Paul!
>
> I have not altered the output in any way. The version of svn was 1.5.4 when the repo was created. After reproducuing the problem a couple times with 1.5.4 I upgraded my test server and client to 1.5.5 just to see if it might have an impact on this issue. It did not.
>
> So to recreate the problem that the developer was seeing on the production server I essentially did this:
>
> 1) Did a restore of a backup of our production server to a test server
> 2) svn cp <url_to_repo>/branches/4.1.00_Dev <url_to_repo>/branches/user_branches/Camille
> 3) svn co <url_to_new_camille_branch>
> 4) changed a couple files in the Camille branch, committed them
> 5) svn cp <url_to_repo>/branches/user_branches/Camille <url_to_repo>/branches/user_branches/Jeff3

Brian,

Is there any explicit mergeinfo on any of these paths (you can check
with a svn propget svn:mergeinfo)?

  <url_to_repo>
  <url_to_repo>/branches
  <url_to_repo>/branches/user_branches

Since <url_to_repo>/branches/user_branches/Jeff3 has no explicit
mergeinfo, it will inherit the mergeinfo from its nearest parent with
mergeinfo. Based only on your naming scheme I'd be suprised to find
that any of these paths *do* have mergeinfo, but I won't to rule out a
bad mergeinfo value on some parent of Jeff3's as a cause of this
problem.

> 6) svn co <url_to_new_jeff3_branch>
> 7) svn merge <url_to_new_camille_branch> <wc_path_to_jeff3>

In steps 5-7 you have basically done this:

  Copy A to B
  Checkout B
  Merge all available changes from A to B

Which, unless you made some more changes to under A after copying it,
is a no-op; there is nothing to merge. Was this intentional? Should
step 4 and 5 be swapped maybe?

> As part of step 4 I believe I did a move on a file to rename it. Other than step 4 I didn't do anything in my WC.

The WC-to-WC copies must have happened prior to your recreation
effort. Could you run 'svn log -vq' on some of the paths with empty
mergeinfo? Somewhere in thier history should be evidence of a
WC-to-WC copy/move, something like this (revisions, author, source
name obviously made up):

------------------------------------------------------------------------
r45115 | programmerbob | 2008-05-23 23:09:08 -0400 (Fri, 23 May 2008)
Changed paths:
   A /camille/platform/src/java/com/sandcherry/tools/common/database/model/vmc/UserProperties.hbm.xml
(from /camille/platform/src/java/com/sandcherry/tools/common/database/model/vmc/UserPropertiesFile.hbm.xml:
45001)
------------------------------------------------------------------------

Then do svn diff -rr45114:r45115
/camille/platform/src/java/com/sandcherry/tools/common/database/model/vmc/UserPropertiesFile.hbm.xml,
was any empty mergeinfo added?

> The really weird part of this to me is that doing the merge anywhere lower than the root works and then I can merge at the root.

Anywhere below the root? You are able to do this merge successfully:
'svn merge <url_to_new_camille_branch>/platform
<wc_path_to_jeff3>/platform'? The reason I ask is that since the only
subtrees with explict mergeinfo under wc_path_to_jeff3 are deeper than
wc_path_to_jeff3/platform. So a merge to wc_path_to_jeff3 or
wc_path_to_jeff3/platform should attempt to merge the same set of
revisions and should almost certainly encounter the same parsing
error.

Paul

> Some other things that may or may not be relevant but that I'll throw out there anyway:
>
> -there are over 50,000 items in this repository
> -this is a young repository. We have only been using svn for about 1 month
> -no one else has access to the test server so there are no changes except the couple of changes I made in step 4 above to any of the branches
> -client is Win32, server is Linux
>
> Thanks again for your attention.
>
> -Brian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1056438
Received on 2009-01-27 09:39:30 CET