bzr merge --weave gives superfluous content conflict

[GuilhemBichot]

I get MySQL 5.5 from https://code.launchpad.net/~mysql/mysql-server/mysql-5.5 at revision
<email address hidden> .
And MySQL 5.1 from https://code.launchpad.net/~mysql/mysql-server/mysql-5.1 at revision
<email address hidden> .
I do
cd 5.5
bzr merge 5.1 --weave # --weave because it's a criss-cross merge
and I get
Conflict adding files to storage/innodb_plugin. Created directory.
Conflict because storage/innodb_plugin is not versioned, but has versioned children. Versioned directory.
Contents conflict in storage/innodb_plugin/ChangeLog
I didn't expect to have a conflict. This file was deleted in 5.5 long ago. In 5.1 we continue to make modifications to it, but all those modifications were already merged in 5.5 before I started the merge above, so I'd expect no conflict to happen.
More details:
- in 5.1:
bzr touching-revisions storage/innodb_plugin/ChangeLog
prints
  3366 added storage/innodb_plugin/ChangeLog
  3405 modified storage/innodb_plugin/ChangeLog
  3455 modified storage/innodb_plugin/ChangeLog
  3461 modified storage/innodb_plugin/ChangeLog
  3493 modified storage/innodb_plugin/ChangeLog
  3498 modified storage/innodb_plugin/ChangeLog
  3509 modified storage/innodb_plugin/ChangeLog
  3538 modified storage/innodb_plugin/ChangeLog
  3567 modified storage/innodb_plugin/ChangeLog
  3583 modified storage/innodb_plugin/ChangeLog
Then I convert revnos to revids (with 'bzr lookup-revision'), and see with "bzr log" that all revisions above are present in 5.5 before I do the merge, except 3583.
So only 3583 can be the cause of the conflict; 3583 is <email address hidden> .
So I try to determine how this revision touched the file in 5.1: it's not present in the output of "bzr annotate --show-ids". So, I tell myself, maybe it deleted a line (which would explain why I don't see it in "bzr annotate"?). So I re-did the merge which led to the creation of <email address hidden> : it's a merge of
<email address hidden>
into
<email address hidden>
(I'm taking the two parents).
I do this merge with "bzr merge", no conflict. And the resulting Changelog file is identical to what is in <email address hidden>, which shows that that revision did no edits on what the merge algorithm had produced. So I believe that that revision has changed nothing by itself, so don't see why it is listed by "bzr touching-revisions", and don't see why I got a content conflict in the first merge at the beginning of this bug report.
Is there a good reason for the conflict?

[GuilhemBichot (guilhem-bichot)]

by the way it's not just me playing with tricky merges; the problem was originally reported by a colleague.

[GuilhemBichot (guilhem-bichot)]

Bazaar (bzr) 2.3.0dev4
  from bzr checkout /home/mysql_src/logiciels/bzr_versions/bzr.dev
    revision: 5540
    revid: <email address hidden>
    branch nick: bzr.dev
  Python interpreter: /usr/bin/python 2.5.2

[John A Meinel (jameinel)]

Note that plain "bzr merge" between those two revisions also has a Contents Conflict on Changlog and creates Changlog.OTHER. It was deleted in THIS, but it existed and was seen to be changed since the deleted revision. Vincent and I will poke at why there is the extra revision that seems superfluous.

[John A Meinel (jameinel)]

For "revno 3583": <email address hidden>
This has 2 parents:
('<email address hidden>',
 '<email address hidden>')

And in parent 0 ChangeLog has:
InventoryFile(... sha1='4fe40887e5637a3684969b6c4e87d311c49d7d43',
  <email address hidden>)
And in parent 1 ChangeLog has:
InventoryFile(... sha1='8fa908462620c547c95dc696ee77c71671496fe8',
  <email address hidden>)
And in the merge revision:
InventoryFile(... sha1='cf22953fbf8a47887c15cb44bf5a3beaba1c8117',
  <email address hidden>)

Looking at the 3-way diff, it looks like 3583 merges the contents of the left parent with the right parent. So it doesn't introduce any *new* text lines, but it does create a new total content. I can attach the 3 files if you want.

The short snapshot is that parent 0 has the lines about:
2011-01-27 The InnoDB Team

 * btr/btr0cur.c:
 Bug#59465 btr_estimate_number_of_different_key_vals use
 incorrect offset for external_size

2011-01-27 The InnoDB Team

 * include/trx0trx.h, trx/trx0trx.c:
 Bug#59440 Race condition in XA ROLLBACK and XA COMMIT
 after server restart

2011-01-25 The InnoDB Team

 * row/row0upd.c:
 Bug#59585 Fix 58912 introduces compiler warning
 due to potentially uninitialized variable

2011-01-25 The InnoDB Team

 * mtr/mtr0log.c:
 Bug#59486 Incorrect usage of UNIV_UNLIKELY() in mlog_parse_string()

2011-01-25 The InnoDB Team

 * row/row0vers.c:
 Fix Bug#59464 Race condition in row_vers_build_for_semi_consistent_read

2011-01-25 The InnoDB Team

 * btr/btr0btr.c, btr/btr0cur.c, btr/btr0sea.c,
 buf/buf0buddy.c, buf/buf0buf.c, buf/buf0lru.c,
 include/buf0buf.h, include/buf0buf.ic, include/buf0lru.h,
 mem/mem0mem.c, page/page0zip.c:
 Fix Bug#59707 Unused compression-related parameters
 in buffer pool functions

2011-01-18 The InnoDB Team

 * include/sync0rw.h, sync/sync0arr.c, sync/sync0rw.c:
 Fix Bug#59579 rw_lock_debug_print outputs to stderr, not to
 SHOW ENGINE INNODB STATUS

2011-01-14 The InnoDB Team
 * btr/btr0cur.c, dict/dict0dict.c, handler/ha_innodb.cc,
 include/btr0cur.h, include/dict0mem.h, include/rem0cmp.h,
 include/rem0cmp.ic, include/srv0srv.h, rem/rem0cmp.c,
 srv/srv0srv.c, innodb_bug30423.test:
 Fix Bug#30423 InnoDBs treatment of NULL in index stats causes
 bad "rows examined" estimates

And parent 1 has the lines about:
2011-01-06 The InnoDB Team
 * row/row0merge.c:
 Fix Bug#59312 Examine MAX_FULL_NAME_LEN in InnoDB to address
 possible insufficient name buffer

2011-01-06 The InnoDB Team
 * dict/dict0dict.c, handler/ha_innodb.cc, handler/i_s.cc,
 include/univ.i:
 Fix Bug#58643 InnoDB: too long table name

And <email address hidden> merges those lines together in the new output.

Which means that the changelog *was* modified since the last revision that was had been merged before the deletion. It happens that both the individual ones were probably already merged, but the combination of their texts was not. (At least as I can sort it out.) So the graph looked somethin...

[Vincent Ladeuil (vila)]

bzr log -<email address hidden> -v says:
...
modified:
...
  storage/innodb_plugin/ChangeLog
...

So the file is indeed seen as modified by the merge.

bzr diff -<email address hidden> storage/innodb_plugin/ChangeLog
=== modified file 'storage/innodb_plugin/ChangeLog'
--- storage/innodb_plugin/ChangeLog 2011-01-30 16:41:58 +0000
+++ storage/innodb_plugin/ChangeLog 2011-02-08 11:52:33 +0000
@@ -50,6 +50,16 @@
  bad "rows examined" estimates

 2011-01-06 The InnoDB Team
+ * row/row0merge.c:
+ Fix Bug#59312 Examine MAX_FULL_NAME_LEN in InnoDB to address
+ possible insufficient name buffer
+
[phone] The InnoDB Team
+ * dict/dict0dict.c, handler/ha_innodb.cc, handler/i_s.cc,
+ include/univ.i:
+ Fix Bug#58643 InnoDB: too long table name
+
[phone] The InnoDB Team
  * handler/i_s.cc, include/trx0i_s.h, trx/trx0i_s.c:
  Fix Bug#55397 cannot select from innodb_trx when trx_query contains
  blobs that aren't strings

[Vincent Ladeuil (vila)]

So, revid:<email address hidden> merged revid:<email address hidden> .

In the ancestry of the later, there is revid:<email address hidden> which modifies storage/innodb_plugin/ChangeLog and since this revisions is not part of the 5.5 history, this generates a content conflict since 5.5 deleted the Changelog and 5.1 modified it since the last merge from 5.1

[John A Meinel (jameinel)]

Quote:
  I do this merge with "bzr merge", no conflict. And the resulting Changelog file is identical to what is in <email address hidden>, which shows that that revision did no edits on what the merge algorithm had produced. So I believe that that revision has changed nothing by itself, so don't see why it is listed by "bzr touching-revisions", and don't see why I got a content conflict in the first merge at the beginning of this bug report.

The merge produced a unique text. This text did not exist in either parent. It wasn't a conflict, and probably a human did not edit the file, but it still represents a unique text in the history of the ChangeLog file. Hence it is marked as "touched". And that shows up as "this file was modified by a revision, that is a child of the version in your ancestry in which you deleted the file."

Note that if I look at the 5.1 branch, I continue to see modification to the ChangeLog file, and I can see those revisions have been merged by the 5.5 branch. So I think this sort of conflict is going to continue to exist. I do believe we have a separate bug for "if a file is deleted in THIS, don't bother treating updates from OTHER as a conflict." Shall we set this as a duplicate of that?