© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
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.