> 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
Received on 2010-05-07 13:52:29 CEST