Comment 6 for bug 113809

> update performing two merges can lead to hard to diagnose situations
> and this should be fixed

It's more than that; the merges can also spuriously conflict.

Consider the this script:

-------------------
#!/bin/sh -x
bzr="/usr/local/bin/bzr --no-aliases --no-plugins"

${bzr} init A
(
 cd A ;
 touch foo ;
 ${bzr} add ;
 ${bzr} ci -m 'start' ;
)

${bzr} co A B
(
 # Make one change, and commit it locally
 cd B ;
 echo '1' >> foo ;
 ${bzr} ci --local -m '1';

 # Make another (but don't commit)
 echo '2' >> foo ;

 # Update to cause a doubled up conflict in foo
 ${bzr} update
)
-------------------

Now, if we commit after that '2', then do the update, you get just
what you'd expect; no conflicts, and a pending merge of 2 revs.

But if you DON'T, you get conflicts, and then you get conflicts of the
conflicts, with the conflict markers being part of the conflict!

-------------------
+ /home/fullermd/src/bzr/bzr.dev/bzr --no-aliases --no-plugins update
 M foo
Text conflict in foo
1 conflicts encountered.
 M foo
Text conflict in foo
Conflict adding file foo.BASE. Moved existing file to foo.BASE.moved.
Conflict adding file foo.OTHER. Moved existing file to foo.OTHER.moved.
Conflict adding file foo.THIS. Moved existing file to foo.THIS.moved.
4 conflicts encountered.
Updated to revision 1.
-------------------

And foo looks like

-------------------
<<<<<<< TREE
<<<<<<< TREE
1
2
=======
>>>>>>> MERGE-SOURCE
=======
1
>>>>>>> MERGE-SOURCE
-------------------

Caramba! It seems to do something odd for the first merge, basing on
the working tree verison or something, which conflicts, then the
second merge adds more conflicts, and you end up with
foo.{BASE,OTHER,THIS}.moved and conflicted conflicts in foo itself.
That's well into "user disdainful" territory.

--
Matthew Fuller (MF4839) | <email address hidden>
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.