On Thu, Mar 22, 2012 at 5:36 AM, Julian Foad <julianf...@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 pretty nicely. 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 -- Thanks Mark Phippard http://markphip.blogspot.com/
