SVN merge attempting to reintegrate on a merge to a branch
Hi, We are encountering an issue when trying to merge trunk to a branch. We originally posted this issue to the CollabNet forums (http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4dsMessageId=499929) but they suggested we should contact this list. We maintain a few branches from our trunk project and we periodically merge back and forth between the trunk project and the branches. When we have work in a branch that we need to reintegrate to trunk we first merge trunk up to the branch and then merge (reintegrate) the branch back down to trunk. We are using SVN version 1.8 so we no longer specify the —reintegrate option as from what I understand the client should now identify what type of merge to do. This process had been working well for until recently when we started getting some errors. We are using Apache 1.8.0 clients, CollabNet Subversion native binaries 1.8.1 (and CollabNet Subversion Edge 4.0.1). Our setup is a fairly straightforward configuration, we have trunk projects in $SVNROOT/svn/trunk/projectname and branches in $SVNROOT/svn/branches/projectname/features/branchname so for example if we have a project called my_project and branch of this project called my_project_branch, they would be in the repository in the following paths $SVNROOT/trunk/my_project and $SVNROOT/branches/my_project/features/my_project_branch. The $SVNROOT is just a variable we use that corresponds the repository URL e.g. https://our.svn.servername/svn. Recently when we attempted to merge a trunk project to a branch (in preparation of doing a merge of the branch back to trunk) we are got errors like the following: $ svn merge $SVNROOT/trunk/my_project . svn: E195016: Reintegrate can only be used if revisions 4401 through 4545 were previously merged from https://our.svn.servername/svn/branches/my_project/features/my_project_branch to the reintegrate source, but this is not the case: trunk/my_project Missing ranges: /trunk/my_project:4485 Missing ranges: /trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-4533 I was not expecting this error because we had previously merged the trunk project to the branch and merged the branch back down to trunk successfully so as far as I'm aware there should be no missing revisions. Also I am surprised that a reintegrate merge is being attempted when trying to merge from the trunk project to the branch project because, as I understand, the reintegrate should only happen when merging content from a branch to a project that the branch was created from. I have run the svn merginfo command which gave the following output: $ svn mergeinfo $SVNROOT/trunk/my_project . youngest common ancestor | last full merge | |tip of branch | || repository path 4400 4545 | | ---| | trunk/my_project \ / \/ --| | branches/my_project/features/my_project_branch || 4531 4541 Can you please help us track down and resolve the issue? I'm not sure if it makes any difference but the branch was created using the repository browser in eclipse with the Subclipse plugin v3.0.0 using Subversion Client Adapter version 1.8.6 Many Thanks, Stefan
RE: SVN merge attempting to reintegrate on a merge to a branch
From: Goor, Stefan [mailto:sg...@thetasgroup.com] Sent: Friday, September 13, 2013 11:40 AM To: users@subversion.apache.org Subject: SVN merge attempting to reintegrate on a merge to a branch Recently when we attempted to merge a trunk project to a branch (in preparation of doing a merge of the branch back to trunk) we are got errors like the following: $ svn merge $SVNROOT/trunk/my_project . svn: E195016: Reintegrate can only be used if revisions 4401 through 4545 were previously merged from https://our.svn.servername/svn/branches/my_project/features/my_project_branch to the reintegrate source, but this is not the case: trunk/my_project Missing ranges: /trunk/my_project:4485 Missing ranges: /trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-4533 Since you sanitized your path names, is there any chance that the t in my_project is being left off on the first missing ranges line? E.g. trunk/my_project Missing ranges: /trunk/my_projec:4485 --- ** Missing 't' in 'my_project' ** Missing ranges: /trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-4533 When I encountered this, the solution was to either merge the branch to trunk (svn merge ^/.../my_project_branch), or to explicitly specify the revision range when merging up from trunk, e.g. svn merge -r 4401:4545 ^/trunk/my_project.
Re: svn.exe crashed when output of 'log' command interrupted
On Fri, Sep 13, 2013 at 3:43 PM, Ivan Zhakov i...@visualsvn.com wrote: On Thu, Sep 12, 2013 at 10:53 AM, Sergey Azarkevich azarkev...@gmail.com wrote: Reproduced on: svn, version 1.8.4-dev (under development) compiled Aug 23 2013, 17:30:38 on x86-microsoft-windows svn, version 1.8.3 (r1516576) compiled Aug 27 2013, 22:13:03 on x86-microsoft-windows svn, version 1.8.0 (r1490375) compiled Jun 18 2013, 13:38:49 on x86/x86_64-microsoft-windows6.1.7601 Windows + cygwin. Steps: svn.exe log | less show first N log entries. Then press 'q' for exit. svn.exe application crashed. Same crash for svn.exe log | more Filed as issue #4425: http://subversion.tigris.org/issues/show_bug.cgi?id=4425 Simple fix is coming soon. Fixed in r1522892 and nominated for backport to 1.8.x. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: SVN merge attempting to reintegrate on a merge to a branch
Hi Andrew, Thanks for your response. You are right, I hadn't noticed but on the first line about the missing ranges the last letter of the project name is missing and I had just pasted over it when I sanitized the path names. I got around this as you suggested by using the -r 4401:HEAD option but this is becoming a recurring problem for us lately. We prefer to merge the trunk project to the branch in preparation of reintegrating the branch to trunk but we seem to hit this issue quite a bit lately. Is this a bug? Is it something we are doing wrong? Is there any information we could send that would help diagnose and prevent the issue? Many Thanks, Stefan On 13/09/2013 18:18, Andrew Reedick andrew.reed...@cbeyond.net wrote: From: Goor, Stefan [mailto:sg...@thetasgroup.com] Sent: Friday, September 13, 2013 11:40 AM To: users@subversion.apache.org Subject: SVN merge attempting to reintegrate on a merge to a branch Recently when we attempted to merge a trunk project to a branch (in preparation of doing a merge of the branch back to trunk) we are got errors like the following: $ svn merge $SVNROOT/trunk/my_project . svn: E195016: Reintegrate can only be used if revisions 4401 through 4545 were previously merged from https://our.svn.servername/svn/branches/my_project/features/my_project_br anch to the reintegrate source, but this is not the case: trunk/my_project Missing ranges: /trunk/my_project:4485 Missing ranges: /trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-4533 Since you sanitized your path names, is there any chance that the t in my_project is being left off on the first missing ranges line? E.g. trunk/my_project Missing ranges: /trunk/my_projec:4485 --- ** Missing 't' in 'my_project' ** Missing ranges: /trunk/my_project:4407-4408,4431,4442-,4485,4524,4532-4533 When I encountered this, the solution was to either merge the branch to trunk (svn merge ^/.../my_project_branch), or to explicitly specify the revision range when merging up from trunk, e.g. svn merge -r 4401:4545 ^/trunk/my_project.
RE: SVN merge attempting to reintegrate on a merge to a branch
-Original Message- From: Goor, Stefan [mailto:sg...@thetasgroup.com] Sent: Friday, September 13, 2013 3:53 PM To: Andrew Reedick; users@subversion.apache.org Subject: Re: SVN merge attempting to reintegrate on a merge to a branch Hi Andrew, Thanks for your response. You are right, I hadn't noticed but on the first line about the missing ranges the last letter of the project name is missing and I had just pasted over it when I sanitized the path names. I got around this as you suggested by using the -r 4401:HEAD option but this is becoming a recurring problem for us lately. We prefer to merge the trunk project to the branch in preparation of reintegrating the branch to trunk but we seem to hit this issue quite a bit lately. Is this a bug? Is it something we are doing wrong? Is there any information we could send that would help diagnose and prevent the issue? No idea. But I posted about the missing char issue a couple of days ago: http://svn.haxx.se/users/archive-2013-09/0116.shtml It's either a harmless presentation error, or the missing char implies a malformed pathname that is possibly mucking up the merge analysis?
Re: svn.exe crashed when output of 'log' command interrupted
On Thu, Sep 12, 2013 at 10:53 AM, Sergey Azarkevich azarkev...@gmail.com wrote: Reproduced on: svn, version 1.8.4-dev (under development) compiled Aug 23 2013, 17:30:38 on x86-microsoft-windows svn, version 1.8.3 (r1516576) compiled Aug 27 2013, 22:13:03 on x86-microsoft-windows svn, version 1.8.0 (r1490375) compiled Jun 18 2013, 13:38:49 on x86/x86_64-microsoft-windows6.1.7601 Windows + cygwin. Steps: svn.exe log | less show first N log entries. Then press 'q' for exit. svn.exe application crashed. Same crash for svn.exe log | more Filed as issue #4425: http://subversion.tigris.org/issues/show_bug.cgi?id=4425 Simple fix is coming soon. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: corrupted svn repository with “serialized hash missing terminator” error
Hi Andreas, Thanks. I think such recovery tools should be there. Probably not as part of 'svnadmin' but at least in contrib. The FSFS verify helped me. I will post the script I used to my website. I am not sure if the attachments are allowed in this list. If allowed, I will post here as well. I am a reasonably good python developer. However I don't know much about svn internals. So if someone is interested in writing such tool, I am willing to contribute. Regards, Nitin On Sat, Sep 7, 2013 at 6:49 PM, Andreas Mohr a...@lisas.de wrote: Hi, On Sat, Sep 07, 2013 at 05:50:29PM +0530, Nitin Bhide wrote: Philip/Stefan/Andreas, Thanks for the help. I was able to write a small python script specific to my needs and recover the repository. It was corrupted revision property file. I have written the details in blog post. [1] http://nitinbhide.blogspot.in/2013/09/recovering-from-corrupted-subversion.html Thanks for openly documenting/sharing your experience! (and of course congrats for your smashing success) Now a question that would spring from this would be whether this is something that could be more automated in Subversion project circles (for this one user who was nicely able to draw the necessary conclusions and then even write his own tool, there's probably a dozen more users who gave up in despair). That's probably not a feature that svnadmin ought to provide (form intermediate revisions out of thin air when encountering corruption in certain revisions), but rather an external recovery tool that's made for that purpose. But those are just random thoughts of someone who's quite external to all this... ;) Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- In theory, there is NO difference between theory and practice. But, in practice, there IS Yogi Berra My company's new product : BootstrapToday - Simple and Sensible Application Lifecycle Management http://www.bootstraptoday.com
