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

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.

Answer 2

Sanders is right.

Do not think as if you are copying states. You "take" changes and apply them again on a different target (which ideally is a relative to the merge origin).

Before svn 1.5 we had to keep track of the changes manually when merging. "Uhm did I merge r28445 to r28501 from this branch? I dont want to reapply changes that I did allready :-/"

It was a headache-machine ;)

svn since 1.5 keeps track of what you did in the past and will only apply the same historical change once to a unique destination.

You should be able to disable this friendly check using " --ignore-ancestry" in your svn merge command. Be prepared to get LOTS of changes in that you applied allready. Narrow down what you want to get by stating the revision.

svn merge --ignore-ancestry -c REVISION_WITH_CHANGE http://mysvn/path/to/mergeorigin