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.
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.