External merge tool support (WIP)

[Maritza Mendez]

On Wed, Aug 4, 2010 at 6:16 PM, Martin Pool <mbp at canonical.com> wrote:

> On 5 August 2010 10:44, Gordon Tyler <gordon.tyler at gmail.com> wrote:> If
> the merge tool terminates with an exit
> > code of 0, the file is marked as resolved as 'bzr resolve <file>' would.
>
> I wonder about that; it seems like often the tool itself will exit
> successfully regardless of whether the conflicts are resolved.
>
>
This is true, at least for the external 3way merge tools I have used.



> To me it seems the main test should be whether the conflict markers
> have been removed.
>
>
You are correct that some flag is needed to indicate whether the "result" of
the merge should actually be considered satisfactorily resolved.  Whether
the bzr merge markers are good for this or not is far from clear to me, as I
will try to illustrate.  A typical conflict-resolution workflow for us goes
like this:


   1. An attempted merge reveals one or more conflicts.
   2. mv *file file.bak*
   3. Developer fires up external merge tool using *file*.BASE, *file*.OTHER,
   *file*.THIS as input.
   (Note that file.THIS does not have conflict markers like *file*.)
   4. Developer makes some choices -- which may or may not be correct! --
   and saves result to *file*.THIS or *file*.RESULT
   5. Developer does something like
      1. cp *file*.RESULT *file*
      2. build and test
      6. Developer iterates over {3,4} as many times as needed to be
   convinced that the merge choices actually captured the desired changes in
   *file*
   7. Developer leaves the desired *file* in place
   8. Developer invokes 'bzr resolve' to tell bzr we're happy.
      1. Note I prefer is this is called 'resolved' (past tense) not
      'resolve' (present, imperative)
   9. finish the merge

I may have made a typo in there but I hope the ideas are clear.  The point
is that the external merge tool doesn't know anythng about bzr conflict
markers.  (An integrated tool would, but we're talking about external
tools.)  So if we really want to support flexible workflows (and I'm not
claiming mine is best; it works for some of us; you probably have your own)
then we might want to be careful about assuming that the presence or absence
of merge markers means anything after a 3way merge tool exits.  This is part
of why I think in terms of "merge - resolve - resolved" where "resolve" is
an imperative to start a 3way merge for conflict resolution and "resolved"
marks a state change after the fact.

Again, I'm not trying to say how things should be.  Anything that works
without cramping workflow is fine.  But this feedback is based on actual
experience watching new people learn to use bzr as much as trying to help
them use bzr well.

~M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100804/ad8b6370/attachment-0001.htm