views:

47

answers:

2

Imagine this scenario:

  1. Alice and Bob both clones a central master Mercurial repository, containing 1 text file
  2. Both Alice and Bob makes a change to the same line in the file, and commits
  3. Bob pushes back to the central repository, but not Alice
  4. Alice now pulls into her repository, notices she now has two heads, and merges
  5. Since the merge is a conflict, she resolves the conflict
  6. Alice then commits but does not push
  7. Bob now makes further changes to the file, in some other location of the file (ie. nowhere near the initial changes) and commits, and pushes
  8. Alice, in her merged file, does a similar change in the same location Bob just changed, and commits
  9. Alice pulls, and discovering yet another dual-headed repository, she merges

Here's a different view of the above scenario

(the numbers after "CHANGE" means that the person changed "portion X" of the file. If both users changed the same portion, we have a merge conflict ahead, if they changed different, not as much)

    Alice                    Bob
    CLONE MASTER             CLONE MASTER
    -----------------------------------------
    CHANGE 1                               <-----+
    COMMIT                                       +-- upcoming merge conflict
    -----------------------------------------    |
                             CHANGE 1      <-----+
                             COMMIT
                             PUSH
    -----------------------------------------
    PULL                                   <-- Bob's change +1 head
    MERGE                                  <-- Attempt to get rid of extra head
    RESOLVE CONFLICT                       <-- Resolve merge conflict
    COMMIT
    -----------------------------------------
                             CHANGE 2      <-----+
                             COMMIT              +-- yet another merge
                             PUSH                |   conflict ahead
    -----------------------------------------    |
    CHANGE 2                               <-----+
    COMMIT
    PULL                                   <-- Bob's change, again +1 head
    MERGE                                  <-- Attempt to get rid of extra head
    RESOLVE ???

At this point, my question is this:

  • Will the merging tools take her first merge resolution into account? Since Bob never pulled in Alice's changes, his copy is still void of any of the changes Alice has made, her initial change (which was in conflict with Bob's), her merge, and her latest change, which is in conflict with Bob's latest change.

If I had simply taken Bob's version of the file, and Alice's version of the file, and given to any merge-program, it would flag both changes as in conflict.

In other words, will the conflict tool try to ask Alice to resolve both the original conflict and the new one, or only the latest one?

I'm guessing (I haven't tried this, still attempting to build some kind of test script to test this problem) that Mercurial will only ask Alice to resolve the latest conflict.

What if I configure Mercurial to use a 3rd party diff/merge program? Will this still apply? For instance, I have configured my installation to use Beyond Compare, will the two files (Bob's with only his changes and Alice's with her changes + the merge resolution) be given with or without the initial resolution present? In other words, if using Beyond Compare, will the correct thing happen here too (assuming it does at all.)

+3  A: 

Mercurial will require only that the latest conflict be resolved, and that will work fine with external change tools.

When Alice does her second merge, she's merging her own previous merge with bob's new delta and only that change needs to be integrated anew.

Really clear diagram, BTW. Thanks

Ry4an
OK, so the scenario will not pose a problem at all, it won't get progressively more difficult to merge changes in "busy" files?
Lasse V. Karlsen
@Lasse V. Karlsen not at all.
msarchet
Yup, it's a pretty normal workflow. Ideally Bob gets better about doing his fair share of pulling and merging, but when bob is an external, upstream project then that's not always possible. Works great.
Ry4an
+2  A: 

It's only going to ask Alice to change the latest conflict.

The reason for this is as follows:

She already has CHANGE 1 from BOB it's in her history so it won't try to change that code again. It works.

msarchet
Good, I managed to fix my test script as well, and confirmed what you and [@Ry4an](http://stackoverflow.com/questions/4016639/mercurial-conflict-merging-further-conflicts-later-on-does-mercurial-remember/4016685#4016685) has answered, and it works nicely, thanks both of you!
Lasse V. Karlsen