On Thu, Mar 22, 2012 at 5:36 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> If anyone wants to try the new symmetric merge code, it's basically in place. It's not finished. It's enabled
> with '--symmetric' command-line option.
I have been doing some simple playing around merging back and forth
between a simulated branch and trunk. Overall, it seems to work
One thing I noticed (not sure if I would call this a problem but maybe
it is something you can improve).
* Merge a branch back to trunk and commit.
* Continue doing some work on both branch and trunk. No merges.
* Merge the branch to trunk again.
This second merge tries to merge some of the same changes from the
first merge. It all works really nicely if you do a merge from trunk
back to the branch before you do this. But if you do repeated merges
from the branch back to trunk it seems to calculate the same base
revision and therefore tries to merge the same changes again.
Another question. Your document talks about cherry picks, but I assume
it is always talking about them in the context of cherry picking an
entire revision from the root of a branch. Does your changes support
subtree merges at all? I have not tried it yet, but I am assuming
this is a case where the sort of checks that reintegrate does would be
important to still have in the code. I know we have talked about
disallowing subtree merges, but this is something we have seen to do
ourselves in our own tree a few times. Considering how infrequently
we use branches, the fact that when we did, people have felt the need
to cherry pick some of those changes back to trunk before the branch
was done does not bode well for removing that as a feature in the
future. Maybe your new code could just detect the reintegrate
scenario is happening and do the additional safety checks before
running the merge. Basically what would happen in the current trunk
if you ran:
$ svn merge --reintegrate --symmetric ^/branch
Received on 2012-03-26 16:37:34 CEST