[RFC] How to better assist users in resolving conflicts

[Vincent Ladeuil]

So far we have only one command when it comes to resolving the
conflicts: 'bzr resolve' with 'resolved' alias.

I've started working on
https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785
to help users resolve conflicts and encounter some issues.

The first one is that the actual command roughly provides two
features:

- mark a conflict as resolved and delete the generated helper
  files,

- check that a text conflict has been resolved.

This can be applied to all conflicted files (--all) or to a set
of specified files (via globing) including a single file (one
conflict can be addressed by any of its related paths).

There is also a special mode 'bzr resolve --auto' that will
detect which text conflicts has been resolved and mark them as
such. It works for the text conflicts *only* (and as such is
incompatible with --all).

The first question raised by the early reviews are whether we
should define new commands to introduce the new ways to resolve
the conflicts.

In my opinion 'bzr resolve' should be the preferred command to do
that and we may keep 'bzr resolved' to simply mark the conflicts
as resolved. 

But then, since that requires break the compatibility with
earlier releases, we may as well keep it as is, delete the alias
and just have an option to mark the conflict as a way to resolve
a conflict among the new ones introduced from now.

In the proposed patch I've called it 'done'.

So, what are these new ways ? As a first step I define only two:
- keep mine: refuse the merged change,
- take theirs: take the merged change.

This is appropriate for tree shape conflicts but for text
conflicts, we may add:
- prefer mine: in conflicted regions, retain my changes,
- prefer theirs: in conflicted region get rid of my changes,
- take both: take my changes and the merged ones.

I think their usage will be limited but still useful (and the
proposed patch doesn't implement them). Manually resolving the
conflicts ought to stay the preferred way though.

I started with 'take this' and 'take other' (to match .THIS and
.OTHER) instead of 'keep mine' and 'take theirs' but I'm open to
suggestions.

I also noticed that we use '.new', '.moved' and '.diverted' in
various cases and I think we should stick with '.THIS' and
'OTHER' when possible as the former are less obvious to casual
users.

And just to mention them (the main goal is to get feedback on
whether we want new commands or not), a couple of other
issues/ideas:

- There are some inconsistencies in the way we generate the
  conflicts as sometimes we give priority to the merged version
  and sometimes we give priority to the version present in the
  working tree,

- The actual implementation is currently unique for all working
  tree formats and that makes it hard to change the attributes
  (to add some missing data including the base revision used for
  example). I'd like to find a way to *avoid* bumping the format
  by considering that people don't upgrade bzr when they have a
  working tree with conflicts (one escape path could be to
  provide a way to just allowing clearing the conflicts),

- 'bzr conflicts -v' could give a more verbose explanation of
  what led to the conflicts mentioning the actual paths and the
  possible actions,

- make --auto handle more conflict types (see comments in the
  patch),

Thanks in advance for your feedback,

       Vincent