Conflicts when merging into branch some changes in deleted code

Question

We've recently created a branch with a version of code customized for a certain client. We're working on both branches at the same time, commiting 'common' changes into the trunk, then merging them to the branch.

Recently, we've come to a troublesome situation. In trunk/bar.c we have (among others) a foo() function. Now, in branch/bar.c the function was removed, as there's no use for it there. The problems occur when foo() is modified in the trunk. When we merge the changes into the branch ("Merge range of revisions"), TortoiseSVN "3-way merge" tool shows a conflict on the method (that is annoying but I can see some reasons in that), but it does also show a whole lot of other changes in the file - which seem to appear out of thin air (looks a bit like if it wanted to show all changes made between the trunk and the branch). And that makes merging much more difficult, as it is littered with some unimportant and old changes.

Did situations like that occur to you? What would you suggest, especially to make spotting important differences easier during merge?

As a (hopefully) temporary resolution I'm going to try and #ifdef out the removed regions, so that SVN would think the code is still there and have better time with merging. (Unfortunately, that's going to make the code a bit ugly, and getting uglier when more functions are removed.)

Answer 1

Well, I'm not a SVN expert, but I can suggest you is to export a patch from a commit of your first branch and to apply the patch into the second branch.

I guess this is almost what the Mercurial 'hg transplant XXX' command does. I don't know if any SVN equivalent command exists, though.

Answer 2

If you change a function on the trunk that you have deleted on the branch, you can expect a conflict, this is natural.

And yes, for the "right-hand-side", you will see all the changes between the trunk and branch. If you think about it, this is the only set of changes that it is logical to show. (At least, that is the case with version 1.4 on the server; later versions with better merge tracking may possibly be able to be more concise, but you would need to have a sufficient client version, I'm not sure. I really need to upgrade ... sigh.) But the branch changes shown should all be automatically marked as unmodified by the merge, unless they conflict or otherwise interact with changes from the trunk.

You should never be surprised by the set of changes you see. If you are, then you have either selected the wrong revisions or you are misunderstanding something about how the merge process works.