Non-expected conflict

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gustavo Niemeyer wrote:
>>Gustavo Niemeyer wrote:
>>| Running bzr blame on the current revision (79) of branch-chris
>>| still shows that Chris is using Gustavo's code:
>>
>>Giving bzr blame output isn't relevant, because we don't use this
>>information for doing a merge (except weave merge, which is not the
>>default and is broken in bzr.dev).
> 
> 
> It is relevant, because it explains the situation, and why I
> expect that the tool *should* be able to handle it.

I was trying to solve *your* problem, and I knew that annotate
information wasn't relevent to *your* problem, because I knew you
couldn't possibly be using our then-broken weave merge.  After we
understand the problem you're having, we can better generalize to decide
how to improve bzr.  It can be frustrating to have to ask for the
relevant information repeatedly.

> One of
> the most important parts of a distributed revision control
> system is the merge algorithm. If you get conflicts just by
> merging from a branch that merges from you, then having
> multiple branches becomes a pain, not an advantage.

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.

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.

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.

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.

> Here's an excerpt of "diff -u test.BASE test.OTHER":
> 
>    if __name__ == "__main__":
>   -    status = main()
>   -    sys.exit(status)
>   +    runner = os.environ.get("TEST_RUNNER", "unittest")
>   +    runner_func = globals().get("test_with_%s" % runner)
>   +    if not runner_func:
>   +        sys.exit("Test runner not found: %s" % runner)
>   +    runner_func()
> 
> Which is surprising. As I've shown in the previous mail, branch-chris
> merged in revision 75 the changes made in branch-gustavo on revision
> 58, so that should be the base, at least, and my changes should be
> included in the "minus" part above.

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.

If we used R75 as a base, then all of the differences between r61 and
R75 would appear to be have been deliberately reversed.

> This is "diff -u test.OTHER test.THIS":
> 
>    if __name__ == "__main__":
>   -    runner = os.environ.get("TEST_RUNNER", "unittest")
>   +    runner = os.environ.get("TEST_RUNNER")
>   +    if not runner:
>   +        runner = "unittest"
>        runner_func = globals().get("test_with_%s" % runner)
>        if not runner_func:
>            sys.exit("Test runner not found: %s" % runner)
> 
> That's precisely the change I did in revision 65 of branch-gustavo,
> and what bzr should understand as the code to stay there without any
> conflicts.
> 
> 
>>I think comparison of THIS, BASE, and OTHER would show that the
>>algorithm is performing reasonably well.
> 
> 
> I now belive that the alogrithm is doing the wrong thing in two
> different ways:
> 
> 1) Got the wrong base

True.  Though as I've mentioned, selecting R61 will actually produce
more conflicts.

> 
> 2) Isn't considering history, which is one of the important
>    aspects that a distributed revision control has to implement
>    to make the branch-hell manageable.

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.

>>  You could also try using
>>--reprocess for merging, which should reduce the conflict regions to:
> 
> 
> As you can see above there isn't another way that would avoid the
> conflict region, if bzr gets those bases and uses non-weave merging.

Agreed.

> Interpreting the graph-ancestry output and the information above, what
> happens is, g62 merges c73, c75 merges g61, g73 merges c79, and gets
> conflicts for changes done in g58.  That's basically what CVS does
> when merging branches, except that you write down the last merge in
> the log and you are aware about what conflicts to expect since you're
> selecting the merging base by hand.

Right.

> So far I've been advertising that as something that bzr was able to
> do, and was hoping that we wouldn't face that kind of problem when
> working with branches.  Whenever I touch a piece of code I know I'll
> get a conflict on the next time I merge from someone that merged
> from me.  How to avoid that? Simple.. use a central integration branch
> and always discard branches after they get merged in the integration
> branch.  But then, Subversion starts to look as an interesting
> competitor.

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

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:

[ALIASES]
...
merge=merge --merge-type weave

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEIYc40F+nu1YWqI0RAkdzAKCH/2rBZ2qMLqVaJuzPAK+XG/zEgQCeOQam
i25PoukyekQs4biyOOXVxRo=
=DD7R
-----END PGP SIGNATURE-----