Explain better when files are deleted in merge source

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

Matthew Paul Thomas wrote:
| Description:
| I just merged from a source that had deleted a file I'd modified. I
| didn't understand what had happened, because:
|
| 1. bzr said "bzr: WARNING: Contents conflict in <name-of-file>". It
| should have said: "bzr: WARNING: Merge source has deleted <name-of-
| file>".

This warning is produced whenever there are conflicting changes
to the content. That could mean that in one tree it's deleted and in
another it's modified, or in one tree it turns into a symlink and in
another tree it turns into a directory, or if the files are binary, or
if both trees create the same file with different contents, etc. There
are a lot of cases, but they are all treated the same in the code.

| 2. The files left behind were "<name-of-file>.BASE" and "<name-of-
| file>.THIS". It would have been more understandable if they were called
| "<name-of-file>.DELETED" and "<name-of-file>.YOURS" or similar.

The files normally left behind for any contents conflict are
1. foo.THIS: the contents of the file that were in your tree before the
merge.
2. foo.OTHER: the contents of the file that were the revision you are
merging.
3. foo.BASE: the contents of the file that was used as a basis of
comparison between foo.THIS, and foo.OTHER. This is automatically
selected, but may be overridden.

These are fairly common terms in three-way merging. I don't think that
calling foo.BASE foo.DELETED would make anything clearer. YOURS might
be better than THIS, but diff3, for example, uses YOURS where we would
use OTHER.

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

iD8DBQFEGBEH0F+nu1YWqI0RApcvAJ0TfOcct+oGiPqZwnPrQu0Yyv7TawCgiMuo
shfSUffwmUJ2wkhM5lVFMmU=
=uFdp
-----END PGP SIGNATURE-----

"There are a lot of cases, but they are all treated the same in the code."

Then I guess that's the real bug: it would be very helpful to know which of those things have happened.

As for foo.THIS, I nearly suggested foo.TREE, since bzr uses TREE for conflict markers. But I think YOURS would be more obvious in both cases.

It's more of a request for enhancement -- the code is working as currently designed but giving a more specific conflict message might be more helpful.

This bug hits us quite often in MySQL. Would be very good to have someone working on it!

I would mention that for the MySQL trees, some of this is caused by the criss-cross merges and having to fall back to an old ancestor.

I have a patch available which improves the path base selection in those cases:
http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48936560.6040106%40arbash-meinel.com%3E

It won't make it into 1.6, but it should land in 1.7, if I can just get someone to review it :)