"bzr merge" fails "Branches have no common ancestor"

[GuilhemBichot]

I get
http://bazaar.launchpad.net/~mysql/mysql-server/mysql-trunk-bugfixing
then I prepare two branches:
$] bzr branch mysql-trunk-bugfixing/ -r <email address hidden> mm
Branched 3131 revision(s).
$] bzr branch mysql-trunk-bugfixing/ -r <email address hidden> jp
Branched 3084 revision(s).
$] cd jp/
jp $] bzr merge ../mm
bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.

This is strange. Both are MySQL branches which have common ancestors (their revno 1 is one, revid:<email address hidden> is another one, and there are tens of thousands of other ancestors).

This merge problem was experienced for real, when creating
http://bazaar.launchpad.net/~mysql/mysql-server/mysql-trunk-bugfixing/revision/3008.2.124

A possible cause is the recent introduction of things from svn:
- there was a svn branch of code
- it was converted to bzr with bzr2svn
- the result was merged into the MySQL branch with
  cd mysql_branch
  bzr merge ../bzr_branch_from_svn
  mv the merged files into a subdirectory
Maybe those revisions imported from svn confuse "bzr merge". But I heard that there were previous similar merges and they worked.
We are using bzr 2.2.

The developer worked around this merge error by expliciting the common ancestor above:
bzr merge -r 'revid:<email address hidden>..' <mysql-trunk-bugfixing path>
succeeded.

[Robert Collins (lifeless)]

I've seen this in another situation too.

Here is what I think is happening; we search for a common merge base by assigning weights to common revisions; if we end up with two (or more) equally weighted revisions, we repeat this recursively.

And I think when we do this, and it hits the start of the branch when there are multiple tails, it blows up.

What it should do, there, is to go into criss-cross weave mode, or something.

[Matthew Fuller (fullermd)]

That would be bug 483388 in that case (though currently the merge type doesn't matter, as it'll still croak on the multiple ancestors before it gets to caring about that).

[Robert Collins (lifeless)]

This may be a dup then.

[Gary van der Merwe (garyvdm)]

Here is an ascii art of the graph of this case showing only relevant revisions:
    * <email address hidden>
   /|
* || <email address hidden>
| ||
* || <email address hidden>
|\ /|
| X |
|/ \|
|| * svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:2315
|| |
|| * svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:2316
|/
* <email address hidden>
|
* rev 1

So it seems it is indeed a dup of bug 483388.

[Gary van der Merwe (garyvdm)]

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

On 16/11/2010 21:54, Gary van der Merwe wrote:
> So it seems it is indeed a dup of bug 483388.

So after further investigation, I now see that this is different to bug
483388. Here is a revised graph exert:

    * <email address hidden>
    |
* | <email address hidden>
| |
* | <email address hidden>
|\ |
| | * <email address hidden>
| \ /\
| X |
| / \ |
| | * svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:2315
| | |
| | * svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:2316
|/
* <email address hidden>
|
* rev 1

It's important to note that the sub graph with root
svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:2316 is
merge twice: by
<email address hidden>, and by
<email address hidden>.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzjDooACgkQd/3EdwGKOh1X8QCghB4XBmFL+v5WWy7hdesT8Cq7
l5kAn3YvB8OpLOUMoOnzyebbzlw5Je28
=XlU8
-----END PGP SIGNATURE-----

[GuilhemBichot (guilhem-bichot)]

I am using the latest lp:bzr, which has the fix above. I am re-running the same commands as when I filed the bug report, with the same revisions. I observe that indeed now, "bzr merge ../mm" does not produce an error anymore. However, it ends with 453 conflicts. When we worked around the bug we used
bzr merge -r 'revid:<email address hidden>..' ../mm
which has 0 conflict.
453 is way too high to be normal, we're never seen that. The same happens with --weave.
I suggest that the newly chosen LCA is wrong. I observe that find_unique_lca() is entered
with ['svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:2315', '<email address hidden>'] as input, and returns "null:".
.bzr.log contains:

0.034 bazaar version: 2.3.0dev4
0.034 bzr arguments: [u'--no-plugins', u'merge', u'../mm']
0.066 encoding stdout as sys.stdout encoding 'UTF-8'
0.107 opening working tree '/home/mysql_src/bzrrepos_new/jp'
[26893] 2010-11-18 21:41:05.530 WARNING: Warning: criss-cross merge encountered. See bzr help criss-cross.
10.109 Criss-cross lcas: set(['svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:2315', '<email address hidden>'])
10.110 Unable to find unique lca. Fallback '<email address hidden>' as best option.
10.115 Base revid: '<email address hidden>'
But I don't see that this is the really chosen LCA, or we wouldn't have that many conflicts.
Notice how this fallback revid is the one we used in our workaround.

[Gary van der Merwe (garyvdm)]

On 18/11/2010 22:50, GuilhemBichot wrote:
> I am using the latest lp:bzr, which has the fix above. I am
> re-running the same commands as when I filed the bug report, with the
> same revisions. I observe that indeed now, "bzr merge ../mm" does not
> produce an error anymore. However, it ends with 453 conflicts.

I did try this merge to test my patch. I ran it the same problem, and
investigated why. The mm branch allready has storage/innobase, which is
added by the jp branch, and unfortunatly has different file ids.

[John A Meinel (jameinel)]

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

On 11/18/2010 4:41 PM, Gary van der Merwe wrote:
> On 18/11/2010 22:50, GuilhemBichot wrote:
>> I am using the latest lp:bzr, which has the fix above. I am
>> re-running the same commands as when I filed the bug report, with the
>> same revisions. I observe that indeed now, "bzr merge ../mm" does not
>> produce an error anymore. However, it ends with 453 conflicts.
>
> I did try this merge to test my patch. I ran it the same problem, and
> investigated why. The mm branch allready has storage/innobase, which is
> added by the jp branch, and unfortunatly has different file ids.

then why does it work when specifying the base explicitly?

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzmpXcACgkQJdeBCYSNAAOi+gCggfaw+pRqz3JpIMUUu6iSsIno
UigAn38FmAhj68Pqu8Yc/PA/CSmodhG+
=nVgY
-----END PGP SIGNATURE-----

[Gary van der Merwe (garyvdm)]

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

On 19/11/2010 18:27, John Arbash Meinel wrote:
> then why does it work when specifying the base explicitly?

Because you are then not trying to merge then other lca
(svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:2315).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzqIc0ACgkQd/3EdwGKOh0nuQCeMlv0DRCQ8uau0dnjm8iFDoN7
DuoAoIgRRTT/mSbViUCTMbtEpCa/pJMT
=FILU
-----END PGP SIGNATURE-----

[GuilhemBichot (guilhem-bichot)]

I looked at the two tips of the merged branches:
<email address hidden>
and <email address hidden> .
The first one indeed has a revision (revno 3009) which removed the storage/innobase directory and added a new storage/innobase directory (converted from SVN). Thus, when doing the merge, any storage/innobase/* file which was modified in the branch of "jonathan.perkin" since the last merge, will conflict with the new file of the "marko.makela" branch.
However, I don't understand why storage/innobase/ha/ha0storage.c gives a "content conflict". I do:
cd mm
bzr missing --theirs -v jp
and I don't see ha0storage.c in the output. Looks to me that it hasn't been modified since the last merge.
If I add --include-merges, I see ha0storage.c in the output, but inside some merge revisions which are said to have been null-merged and should thus not cause a conflict (and that's why I then dropped --include-merges: I wanted to see the actual changes done, not those done and null-merged).
Not a big deal anyway, we are normally not going to find ourselves in such a situation of so big directory changes, anymore.
So we can close this.