svn merge with --reintegrate complains about missing ranges but mergeinfo seems correct

Question

I have a project with with the following structure

^/project/trunk
^/project/branches/mybranch

where current HEAD is revision 1048. The branch was copied from trunk in r523. trunk has been merged to mybranch with the result being r1048. The mergeinfo on ^/project/branches/mybranch gives

/project/trunk:523-1047

and the mergeinfo of trunk has no record mentioning anything from ^/project/branches/mybranch. Actually in reality both trunk and branches also hold mergeinfos from branches parallel to mybranch but those mergeinfos appear as absolutely identical in both outputs.

Now I go into my working copy of trunk and try to issue

svn merge --reintegrate ^/project/branches/myproject

I get an error message that says:

svn: Reintegrate can only be used if revisions 523 through 1048 were previously merged from file:///home/svn/project/trunk to the reintegrate source, but this is not the case:
  project/branches/mybranch/src
    Missing ranges: /project/trunk/src:523-1047

That is weird because the mergeinfo on my branch folder tells me that 523-1047 have been correctly merged from trunk to branch. What is the deal with that subfolder? src is a directory that obviously exists in both trunk and branch.

I think that is where something is fishy. If I look into the mergeinfo of mybranch/src via svn pg svn:mergeinfo ^/project/branches/mybranch/src@HEAD I get nothing at all. If I look at the trunk/src however (svn pg svn:mergeinfo ^/project/trunk/src@HEAD) I get

/project/branches/mybranch/src:784

So it seems as though someone did a cherry-pick from branch to trunk there. However this does not appear in the trunk folder itself.

Is that where the trouble lies? And most importantly: how can I cure it??

Sweaty

Answer 1

Is that where the trouble lies?

Yes, exactly - merge subtree later always confuse reintegration

And most importantly: how can I cure it??

Remove mergeinfo from /project/trunk/src

Cowans

Unfortunately this didn't worked for me. My branch and the trunk were identical in the content, but probably for some reason they were different in the svn tree structure. I had to create a new branch from the trunk and I was forced to delete the old branch, now it works but obviously this is not the ideal solution. – Kickapoo

I know this is years old, but I'm curious why removing the record of the cherry pick is the right answer? I suppose you're saying that once that is removed and the merge in either direction is successful, then the history of the path in question will be correct in spirit in that the content that used to be merged is now really at the new merge point and no longer at the old cherry pick revision? Is this correct? – Marucci

@Marucci - it was the correct answer for 2013 (and then version of SVN). AFAICR, --reintegrate option have "deprecated" status from 1.8 long time ago and current behaviour of "subtree merge" have to be re-checked with actual SVN – Cowans

Answer 2

Here is a very similar topic you might want to have a look at:

Reintegrate can only be used if revisions were previously merged URL to reintegrate the source

Especially this answer from Paul Whipp has helped me a lot when I encountered the same problem and didn't want to delete the mergeinfo, because this somehow sounded like a workaround and not a "real" fix.

In short: Try to merge the missing information manually for that specific file/ folder (just as svn suggests). Worked like a charm for me.

See Pauls answer for the corresponding code excamples, etc.

Lase