Hi Stefan, I just saw your message so I won't post to the dev list just yet. These are the details I was going to post:
----------START---------- We are using Apache 1.8.0 clients, CollabNet Subversion native binaries 1.8.1 (and CollabNet Subversion Edge 4.0.1). I am working on OSX 10.8.4 and I am using the apache source compiled with the following instructions: http://samoldak.com/updating-to-svn-1-8-for-mac-os-x-10-8/ (this uses serf). We have found the same issue on a packaged version of the svn 1.8 client from Wandisco. The issue we encountered is that SVN is trying to do a reintegrate when attempting to merge a trunk project to a branch of that same project and it (incorrectly) complains about missing revisions and some paths in the error message are truncated. 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 ^/trunk/my_project . svn: E195016: Reintegrate can only be used if revisions 4401 through 4579 were previously merged from https://our.svn.servername/svn/branches/my_project/features/my_project_bran ch to the reintegrate source, but this is not the case: trunk/my_project Missing ranges: /trunk/my_projec:4485 Missing ranges: /trunk/my_project:4407-4408,4431,4442-4444,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 it, the reintegrate should only happen when merging content from a branch to a project that the branch was created from. As if you looking at the first line missing ranges section it has truncated the last letter of the path. I have run the svn merginfo command which gave the following output: $ svn mergeinfo ^/trunk/my_project . youngest common ancestor | last full merge | | tip of branch | | | repository path 4400 4579 | | -------| |------------ trunk/my_project \ / \ / --| |------------ branches/my_project/features/my_project_branch | | 4531 4579 And when I do the svn merge info on trunk I get the following: $ svn mergeinfo ^/branches/my_project/features/my_project_branch ^/trunk/my_project youngest common ancestor | last full merge | | tip of branch | | | repository path 4400 4531 4579 | | | --| |------------ branches/my_project/features/my_project_branch / \ / \ -------| |------------ trunk/my_project | 4579 I tried to do the same merge using an SVN 1.6 client (to checkout and merge) and the merge worked as expected so I suspect that this a client bug. Could you please help to diagnose this issue? Please let me know if any further information is required? Unfortunately I have not be able to come with a deterministic set of steps to reproduce the issue. I have had to work around the issue by using the r option to svn merge e.g. svn r4400:HEAD ^/trunk/my_project . ----------END---------- I'm not sure I understand what you mean by "Does the corruption happen also if you use file:// URLs on the server during checkout/merge, instead of http:// ?". Our SVN server is remote to our development machine so the only way I do the merge is using a URL with http:// into a local working copy (WC) so that I can resolve in the WC any conflicts before committing. Could explain a bit more what you mean by this so I can send on some more information? Many Thanks, Stefan On 16/09/2013 10:34, "Stefan Sperling" <[email protected]> wrote: >On Fri, Sep 13, 2013 at 04:16:17PM -0400, Andrew Reedick wrote: >> > -----Original Message----- >> > From: Goor, Stefan [mailto:[email protected]] >> > 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? >> > >Hi Andrew, > >did you have time to answer Ivan's questions from this post? >http://svn.haxx.se/users/archive-2013-09/0142.shtml > >Knowing where the mergeinfo corruption starts occurring would >help us greatly with hunting down the issue. > >Does the corruption happen also if you use file:// URLs on the server >during checkout/merge, instead of http:// ?
