bad idea, and should be discouraged. A revision that contains svn:mergeinfo changes should only contain the file and structure
> changes logically equivalent to the revisions that have been merged.
Sure, but back to Joël's question: that still does not mean SVN can assume this "merge changset" never needs to be merged back and you shouldn't have to cherry-pick around it.
Let's say we have source code or scripts in our repository. r10 changes a parameter to a function and adapts all callers. You merge r10 into a branch, but earlier in the branch you had added another call to the function. You need to fix the call before the merge is logically complete. You could still commit the "raw" merge first and the logical completion of the merge as a second changeset. In fact, that's what you would have to do to allow pristine cherry-picking from your branch back to the trunk.
So let's make it a little tougher: both branches have changed a parameter of the same function. Merge conflicts all over. You want all the help you can get to resolve those conflicts. So you call on your compiler, test suite, whatever. It's next to impossible to separate this merge into a "raw" merge and changes due to interference of the merge and earlier changes in the branch.
-- Stein
