Comment 6 for bug 588698

Revision history for this message
GuilhemBichot (guilhem-bichot) 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. 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.