Re: Symmetric Merge

Mark Phippard wrote:

> 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.

Thanks for trying it and reporting back, Mark!

> 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.

Sounds like a bug; it's supposed to avoid doing that.  Can you post the transcript?

>  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.

Did you see it printing out the same base revision(s) in its debug prints?

> 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.

Your assumption is correct: I use the phrase 'cherry-pick' only with reference to revision numbers, not sub-trees.  I'd like to stick to the phrase 'subtree merges' for when a subtree's mergeinfo differs (substantively) from its parent's.

>  Does your changes support subtree merges at all?

Yes it does.  Having determined the location of the base for the initial (root) merge, it then runs the same code that is run by a 1.7 'sync' or 'reintegrate' merge.  That code handles subtrees according to their own mergeinfo, in some manner.  So, the short answer is that I expect it to handle subtrees in the same way that 1.7 'sync' and 'reintegrate' merges do, with the only difference being that the high-level code chooses which of those two it runs regardless of whether you specify the '--reintegrate' flag.

I'm still far from clear what the subtree-handling code does in theoretical/algebraic terms.  That's one thing I need to analyze, so I can state more definitely what I think it should do and what it does do, and your question prompts me to get on with that.

>  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.  [...]

I intend to support subtree merges.

I'm unsure what you're saying here.  Maybe: "Given that the existing 'reintegrate' code can't (or isn't guaranteed to) handle switched subtrees, I need to ensure that when the automatic 'symmetric' merge code chooses the base-on-target-branch (that is, 'reintegrate-type') merge code path, then it performs the check for no switched subtrees, even if the user didn't specify the '--reintegrate' flag."  That may be so; I need to investigate.

Or are you talking about disallowing some kinds of subtree mergeinfo scenarios?

- Julian
Received on 2012-03-26 19:53:34 CEST