SVN merge reintegrate missing ranges but nothing to merge

Question

Here is the riddle:

C:\code\trunk> svn merge --reintegrate http://svn.e.com/repos/branches/lih --accept postpone --dry-run
svn: E195016: Reintegrate can only be used if revisions 11430 through 12384 were previously merged from http://svn.e.com/repos/trunk to the reintegrate source, but this is not the case:
  branches/lih
    Missing ranges: /trunk:11902

But then if I go into the branch's directory and try to merge that range, there is nothing to merge!

C:\code\branches\branch> svn merge -r 11901:11902 http://svn.e.com/repos/trunk --accept postpone --dry-run
C:\code\branches\branch>

Even svn merge -r 11898:11903 shows nothing to merge.

Now I seem unable to reintegrate my branch into trunk! Please help!

P.S. The lih branch wasn't created until 11906. It was branched from the hd branch, which was branched from trunk (and hd has already been merged back into trunk).

Answer 1

This seemed to work for me, but I can't claim to understand it or vouch that it's the best way to resolve my problem.

First, it's important that your branch has all the latest commits to trunk. So sync it up (do a merge from trunk to branch).

Then you can essentially force a reintegrate by doing this in the trunk directory: svn merge http://svn.e.com/repos/trunk/@REV http://svn.e.com/repos/branches/lih/ . --dry-run (but replace REV with the latest revision #).

Answer 2

I just ran into something similar, where the issue was that trunk had had two cancelling revisions (i.e., rev 20865 on trunk undid rev 20857). So when I first merged from trunk to branch, it didn't have anything to merge for this pair of revisions, but didn't include them in the mergeinfo for the files in question. Then when I tried to merge back from branch to trunk, it objected that these two revisions were missing.

My solution (after manually verifying that the revisions cancelled for the files in question) was to merge each of the two revisions to branch explicitly (via svn merge ^/trunk -c 20857, and svn merge ^/trunk -c 20865), commit, and then merge the branch back to trunk. The second time, it went smoothly. This was with Subversion 1.8.0 (r1490375).

I was able to get around a similar problem earlier using merge with --record-only to mark the changes as properly merged on the branch, but it's probably safer to merge the actual files (just in case there's a change that doesn't quite cancel).

Looks like a bug in the way Subversion 1.8 handles mergeinfo for cancelling changes to me.