Non-expected conflict

[Jan Hudec]

On Wed, Mar 22, 2006 at 15:14:29 -0300, Gustavo Niemeyer wrote:
> 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).

I'd like to add that none of monotone, git, mercurial, subversion or
svk, nor any commercial versioning tool I've ever heard of, would do
any better. Some of them, eg. monotone, would choose the dominator
revision, which would give more, but less confusing, conflicts.

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

The weave merge is basically the same idea as 'precise codeville merge'.
Making that the default would give bzr a feature that would be hard to
match by other tools.

Darcs merging is based on it's patch algebra and is not usable without
that.

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

That would sure be useful. Weave merge can't be properly debuged when
noone will use it.

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

We should however try to think about what could be useful for
understanding conflicts when they happen. Maybe some kind of annotation
or synthetic base.

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

It won't happen with subversion because noone will ever think about
merging there given how complicated it is. It however /will/ happen with
git, monotone or svk, as I already mentioned.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060323/372573bd/attachment.pgp