Subversion: Merge, Revert, Merge again. Why does it silently fail?

Question

Is this a nasty Subversion bug or am I approaching it the wrong way?

Merge a branch into a trunk. ->HelloWorld.txt updates

Revert HelloWorld.txt

Do the same merge again. ->No files update.

Why doesn't the second merge update HelloWorld again? It's acting as if that change has already been copied over. Shouldn't the revert reset it?

If you revert the entire folder HelloWorld is in, the second merge properly applies the change again. It's only if you revert a file that it fails.

This is a little scary. What if I need to revert some files for now. Any future merge will silently fail to copy over critical code.

Subversion 1.6 OS X 10.6.4

Answer 1

This comportment is documented in svn documentation Advanced Merging section (see note 23). When you first merge your change, the merged revision number is tracked in the svn:mergeinfo property. If you undo your changes, the revision is still marked as merged, to prevent you from merging it again by mistake. The fact is that if you removed it, there's little chance you want it back...

If however you really want to merge it again, then you can use the --ignore-ancestry option that will not check in svn:mergeinfo if the revision has been merged previously. Another solution is to deliberately remove this revision from svn:mergeinfo, so that it can be merged again in the future. But don't do it by hand, use the --record-only option of the svn merge command for that.

Answer 2

Subversion performs merge tracking, meaning it will record what revisions have already been merged. The merge info is recorded in a property called svn:mergeinfo on the root of the merge (ie whatever you entered as target after svn merge). You reverted the file, but probably didn't revert the merge root that contains the modified or added svn:mergeinfo property.