RE: Re: Unable to parse reversed revision range
From: Brian Rieck <BRieck_at_sandcherry.com>
Date: Mon, 26 Jan 2009 16:39:37 -0700
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:
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):
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.
On Mon, Jan 26, 2009 at 4:21 PM, Brian Rieck <BRieck_at_sandcherry.com> wrote:
Is there any explicit mergeinfo on any of these paths (you can check
Since <url_to_repo>/branches/user_branches/Jeff3 has no explicit
> 6) svn co <url_to_new_jeff3_branch>
In steps 5-7 you have basically done this:
Copy A to B
Which, unless you made some more changes to under A after copying it,
> 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
Then do svn diff -rr45114:r45115
> 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:
> Some other things that may or may not be relevant but that I'll throw out there anyway:
This is an archived mail posted to the Subversion Dev mailing list.