Confusing (and probably not a real) merge conflict

[Wilmer]

Hello,

First of all, I think I know the cause of this problem already, it's a bad move from my side:

For BitlBee I have a devel branch and I've been working on a libevent branch (with alternative event handling) for a while already. Since that branch was going to be merged eventually anyway, I used the libevent branch as a base for other working branches (the XML storage branch being one of them) instead of using devel. By now I finally merged libevent into devel and now I'm having troubles.

When I try to merge new changes from the main development tree into the XML storage branch, I get lots of merge conflicts, and they all look a bit like this:

{{{
File: proxy.c

#include <fcntl.h>
#include <errno.h>
#include "nogaim.h"
#include "proxy.h"
<<<<<<< TREE
#include "base64.h"

=======

>>>>>>> MERGE-SOURCE
char proxyhost[128] = "";
int proxyport = 0;
int proxytype = PROXY_NONE;
}}}

There were no changes in the remote/merged tree at all at this place, only the base64.h addition in the local file. I just checked the proxy.c from a couple of weeks ago and this part of the file is exactly the same as in the current version. So what's the conflict exactly? :-/

Another strange thing is, I moved some files to a different directory. During the first merge this didn't cause any problems, but during a later merge suddenly bzr thought I was moving them back to their old place again.

It should be possible to reproduce the problem by trying to merge the following tree:

http://code.bitlbee.org/wilmer/storage-xml/ (get revision 182)

with this one:

http://code.bitlbee.org/bitlbee/ (get revisioin 171)

I'll try to sort out this mess myself now, and keep this problem in mind when messing with too many branches again. :-)

[John A Meinel (jameinel)]

This still is the case in bzr-0.11. I looked at the ancestry graph, and I don't think the specific problem is that you split off of the event branch rather than the main dev branch. That might have made things simpler, but part of what happened is that we have 3 branches, dev, event, and storage. storage comes from event.

In preparation for something, you merged dev into storage. And then in the next revision, you merged event into dev. Which creates some weird crossings in the ancestry. This isn't strictly wrong, but if you had merged dev into storage *after* you merged event into dev, things probably would have been cleaner.

If you do 'bzr merge --show-base', you can see that both trees think that you removed some #define lines.

Only in one of them you also added '#include "base64.h"', and the other one just has a blank line.

Most likely, these lines were removed in the event branch, but because of the base that got chosen, it shows up as a change in both branches.

Now, if you use 'bzr merge --merge-type=weave' lib/proxy.c has no conflicts. Because that uses a more advanced mechanism, which knows that the lines being removed were removed in the ancestry of both branches, so the new lines replace the existing ones.

We have the ability to do weave merging (annotation based merging), and we have considered making it the default. It is just something that we need a little more experience with, because the output can be a bit different than the default diff3-style merging.

It might also be possible that a per-file ancestry graph would resolve this (also something we are considering).

I'll upload a truncated (but still large) ancestry graph of the involved revisions in a second.