Non-expected conflict

[Gustavo Niemeyer]

Hello Aaron,

> Diff3 is the conservative choice in text merge algorithms, and is our
> default  No one is claiming that it is aware of the derivation of
> lines, or that it handles criss-cross merges well.

I understand, and I don't want to look like I'm blaming someone.
I just belive that we're sticking to the wrong default.  Even
though bzr is growing some very cool svn/cvs-like features lately,
most of us still consider that being able to follow a distributed
model has interesting advantages.  Someone doing that will
certainly step through the problems we're facing, since the path
is straight ahead in the road of someone doing distributed
revisioning (A merges B+B merges A == conflict).

> Newer merge algorithms such as bzr's weave merge or Codeville's
> Precice Codeville Merge are aware of the derivation of lines, so they
> can perform better in criss-cross and with cherry-picks.  Darcs has an
> alternative approach that also handles these.

I see having one of these as the default algorithm for bzr as a
major point towards bzr success.

> However, the way these newer approaches work is not very intuitive,
> and so when they go wrong, they can be much more confusing than diff3,
> which is somewhat well-understood.

In the project I'm currently working we're getting dummy conflicts
several times a day.. every merge has a spurious conflict.

If these considered-better merging algorithms have problems, I belive
we should stick one of them as the default, and fix these problems,
rather than hiding them in a barely tested code path.

> We have, so far, been leery about making changes to our default merge
> algorithm, partly because weave merge is hasn't seen a lot of real-world
> use.  So if you want to test weave merge out, by setting it up as your
> default, that would be a very useful step.

We have an ideal environment for that.  I'll talk to Jeff Bailey to
check if we can get a bzr version with fixed weave merging in Dapper,
so that we can make it the default.

> The BASE text should be the exact contents the version of the file in
> revision R73, because that was selected as a common ancestor.  We do not
> use sythetic bases for diff3, and weave merge doesn't have a BASE at all.
[...]

Understood. Thanks for explaining.

> If we define 'doing the wrong thing' as something different from 'has a
> bug', I can agree with you.  It seems to be an accurate implementation
> of a merge algorithm that can't cope very well with criss-cross.

Agreed.

> I believe that bzr is an improvement on Subversion even in the
> centralized scenario.  I should mention that it's possible to get
> criss-cross even there:
>
> 1. push your branch to a public location
> 2. merge from the central branch into your private copy.
> 3. merge your public branch into the central branch

Indeed. :-(

> But you're right that it would be much nicer if we could handle
> mesh-merge better.  Weave merge is now fixed, and it works more the
> way you seem to expect a merge algorithm to behave, so, it would be
> very helpful if you could test it.  You can make it your default by
> adding an alias to your ~/.bazaar/bazzar.conf:

I've tested, and ** IT WORKS **! Fantastic!

Again, we should think seriously about making it the default algorithm.
Most people will not run after the reason why these conflicts happen,
and will just blame bzr.

While the same thing would happen in Subversion and whatnot, the
common way of using these tools doesn't turn the problem into
something unexpected. On the other hand, Bazaar was made to explore
distribution more aggressively, turning A-merge-B+B-merge-A into
the obvious path, and "conflicting with my own changes" a boring
issue.

Thanks for your support,

-- 
Gustavo Niemeyer
http://niemeyer.net