bzr merge fails if deleted contents differ

Aaron Bentley aaron.bentley at utoronto.ca
Sun Oct 2 23:32:00 BST 2005


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

Martin Pool wrote:
> Here is a draft specification for handling conflicts.

This is a good start.

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

Fully agreed.

> 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.

Working on it.

> 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".

More details on how/where would be helpful here.  I suppose we could
have .bzr/conflicts...

> 
> The tree ... needs to obey ... constraints on
> the inventory.  

Hmm.  Can the duplicate ID case always be handled as name conflict for
file, or is it a separate class?

> 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.)

I'm concerned that considering non-present files as unconflicted would
make some conflict cases confusing.

> 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:

Specifically, I think we should take OTHER, because users can easily
revert that, but it's hard to pick OTHER when THIS has been taken.

We're kinda doing that right now (not handling the id move yet).  Right
now I'm calling them foo.moved, but maybe foo.THIS would make more sense.

> 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.

To an extent, users need to know about file-ids, because they need to
understand why parallel imports aren't mergeable.

> It might be better to just take the local file-id and
> merge the texts.  

I'm not sure it's defensible for us to merge two logically-independent
files.

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

iD8DBQFDQF/f0F+nu1YWqI0RAo2gAJ49J+cqkYOXBYjW+LtR5os+TtSClgCfZMYV
w7yC8yOOHYJOVEH4tyK3Qvg=
=DHjE
-----END PGP SIGNATURE-----




More information about the bazaar mailing list