Contents conflicts for binary files are confusing

[Paul Pelzl]

When bzr encounters a conflict while merging changes to a binary file, the working tree is modified as follows:

renamed:
  foo.bin => foo.bin.OTHER
modified:
  foo.bin.OTHER
unknown:
  foo.bin.BASE
  foo.bin.THIS

I believe this model is unnecessarily confusing. A common case is that a developer would like to resolve the conflict by selecting either THIS or OTHER as the merge result. Due to bzr's behavior, these two options turn out to be weirdly asymmetric:

Accept "OTHER":
    bzr mv foo.bin.OTHER FOO.bin

Accept "THIS":
    mv foo.bin.THIS foo.bin.OTHER; bzr mv foo.bin.OTHER foo.bin
or perhaps more cleverly but less clearly:
    bzr revert foo.bin

Both of these solutions look oddly dissimilar from the analogous "Text conflict" case, where a single file-move can get the job done.

In practice, this behavior is a very real problem for users without strong bzr familiarity. I would like to see the conflict resolution model for binary files resemble that of text files.

[Martin Pool (mbp)]

vila is working on a ui like this.

[Vincent Ladeuil (vila)]

Work in orogress is summarized at http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution

Feel free to update (it's a wiki) or give feedback,

[Jeff Webb (jeff-webb)]

I strongly agree that the conflict resolution model for binary files needs to be consistent with the one for text conflicts. For example, we recently had a user attempt to resolve a binary conflict like the one mentioned above in the following manner.

$ cp foo.bin.OTHER foo.bin
$ bzr resolve foo.bin
$ bzr status
removed:
  foo.bin
unknown:
  foo.bin

This resolution method would work fine for a text conflict, but ends up removing the file in the case of a binary conflict. Unfortunately, the user did not catch their mistake, and committed this change to the branch.

I am of the opinion that bazaar doing a 'bzr mv foo.bin foo.bin.OTHER' in the event of a conflict is completely wrong. I cannot imagine a case where someone would want to add a file called 'foo.bin.OTHER' to their branch, so why does bzr do this? I understand that the situation for binary files is a little different from text files in that one can't put the usual conflict markers into foo.bin, but I am convinced that the current behavior is very confusing and a better solution can be found. If someone likes the current behavior, I would appreciate an explanation of why it is a good solution.

I think bazaar should generate foo.bin.OTHER, foo.bin.THIS, and foot.bin.BASE files that are not part of the branch (just like with text conflicts), but the real question is what should be the contents of foo.bin? I see three viable options: the content should be (1) the same as foo.bin.OTHER, (2) the same as foo.bin.THIS, or (3) some 'dummy' content that bzr won't accept as resolved unless it is modified. Any of these would be better than the current behavior.

Many thanks you all for your work on bazaar. We chose to use this revision control system because it is well designed, extremely flexible, and easy to use, but I think this aspect slipped through the cracks, and needs to be fixed.