bzr merge fails if deleted contents differ

Martin Pool martinpool at gmail.com
Thu Sep 29 23:27:01 BST 2005


Here is a draft specification for handling conflicts.  (This message
could be turned into a test suite for the conflict handler.)

All merges will complete, possibly with conflicts.  That is to say,
every conflict must be handled somehow, without causing the merge to
fail.

The basic approach is to put into the working directory the tools the
user will need to resolve the conflicts, and to then let them
manipulate the tree to be the way they want.  This is what we do with
file conflicts, by inserting conflict markers and giving three files.

Conflicts should be remembered so that you don't accidentally commit a
tree with text or shape conflicts.  The code in bzrtools seems to work
well, so we should bring it across.  The explanation of what
conflicted should be stored so that users can be reminded of it later,
e.g. the status command should say something like "file foo modified
<=> deleted".

The tree should always be well-formed: obviously it needs to obey
filesystem constraints (no duplicated names) and also constraints on
the inventory.  So it should always be possible to say "bzr resolve
--all ; bzr commit" and have it succeed, even if the results might be
meaningless.

Applying these rules, in the case of modified vs deleted, the modified
text should be present so the user can see it, the file is marked
conflicts.  If the user wants to keep the modified file, they can just
mark it resolved.  If they want to delete it, they just delete it
(which implicitly resolves it.)

If two file-ids want the same name we should rename one of them in the
inventory and in the working directory, and again let the user chose:
they can delete one or both, possibly textually merge them, etc.

(Perhaps this is not ideal, because it exposes the idea of a file-id
to the user.  It might be better to just take the local file-id and
merge the texts.  Or we could add the concept of merged file ids, but
let's get this going first.)

I'll put some other cases up on the wiki.

--
Martin




More information about the bazaar mailing list