SVN merge is not merging anything for some revisions

Question

We are using Subversion and TortoiseSVN. We use the trunk for development and branches to represent stable releases. Changes (bug fixes) that are made on a branch are subsequently merged back to the trunk. We are not experts in subversion, but in general this works well for us.

Recently I was merging a bunch of changes from a branch to the trunk, and I got to one revision where the merge does not do anything.

Command    Merging revisions 7233-7234 of .../branches/RB-7.2.0 into C:\Core, respecting ancestry
           C:\Core  
Finished!   

The branch revision clearly has changes associated with it, the files involved are not new, and the changes do not appear in my working copy of the trunk, so I don't know why it's not working. It appears there are several consecutive branch revisions behaving this way (involving several different files), then the ones after those behave normally.

I know it's possible to block revisions from being merged, by marking the merge as record-only (the revision is marked as merged even though it isn't.) So the only thing I can think of is that these revisions have been blocked somehow. In the trunk, the files that should be merged do not appear to have anything in the mergeinfo property, and neither do any of their parent folders. But I'm not certain whether / where I would expect to see that information. Also, the "show log" dialog from the merge dialog seems to be showing all revisions, including those I've already successfully merged, regardless of whether "include merged revisions" is selected.

So my questions are as follows:

• Is there any way to confirm this theory of revisions being blocked?
• If the revisions are blocked, is there any way to unblock them?
• If they are not blocked, what else should I look at?

Update: After confirming that the problem is not related to the revisions being blocked, I tried the merge again from the command line instead of through tortoise. It did the merge (yay!) but now that I'm looking at it, I notice that the mergeinfo is not updated for any of the changed files, only for 6 unrelated files that already had mergeinfo. I'm not sure whether to be concerned about this. I still don't know why tortoise is not working, but at least I can get my work done.

Answer 1

When Tortoise does the merge, it will only use the mergeinfo property to determine which revisions to merge if you leave the revision box empty. So, you 'unblock' the revision, just merge that one explicitly. Tortoise doesn't list the already-merged revisions in the log

Tortoise might record the merge in mergeinfo again, so have a look at the directory's svn properties afterwards to see if it does that (and edit the extra entry out - though I think the server will do this, its easier to do it manually sometimes).

The alternative way, is to look at the mergeinfo prorperty and see if this revision is already listed, if so, remove it and commit. Then repeat the merge and it should work as you expect.

The destination usually has the mergeinfo, but I'm guessing that in your ase the branch also has some which might be blocking the merge. Let us know if this is the case, I'd be interested to see what's actually happening for you.

Answer 2

It's possible the merge was recorded. To double check, From C:\Core (looks like your trunk checkout):

svn propget -R svn:mergeinfo > mergeinfo.txt 

Search through the resulting file to see if the revision #'s in question are listed. Remember - this is TRUNK you want to check, since it is the target of the merge.

It may be listed as a range, so a straight # search may not work (.e.g. file might list 7230-7240, not 7234) If not, something else is going on - if so, maybe the merge was recorded on a file or folder that had not been checked.

I'm not sure how to reverse the mergeinfo recording without manual editing (NOT RECOMMENDED), but you can force it to re-merge the revision(s) by passing --ignore-ancestry. If that causes the merge to do something, then svn thought the merge already happened and you should have seen evidence above.

If the merge isn't already recorded and the above steps did not solve it, check the svn mailing lists for ideas.