Conflict resolution workflow (was Re: Recipes vs. Looms vs. pipelines)

[Aaron Bentley]

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

Barry Warsaw (by way of Barry Warsaw <barry at canonical.com>) wrote:
> BTW, this thread reminds me of a workflow wart that I'd like to get
> some advice on.
> 
> I can't commit
> that until I've resolved the conflicts, but once I do, I have no way
> to know what part of that work came from the trunk merge and what
> part of the work came from my resolution of the conflicts.

Annotate will know which lines came from earlier versions, which
admittedly isn't quite the same thing.

> I would like to split this task into two parts.  I want a revision
> that is the results of the merge of trunk, and a separate revision
> that includes just my changes to resolve the conflict.

Which one would be marked as a merge?  If you mark the commit from the
automatic merge as a merge, then you'll mess up future merges because
the base is unclean.  If you mark the commit after manual resolution as
a merge, then all the of automatic merges will look like your own work.

The results of an automatic merge are pretty simple to reproduce, so I'm
not sure that it makes sense to commit that.

> With that it
> would be much easier to identify, diff, review, and modify just the
> changes I had to make to resolve the conflict.  It's entirely
> possible that I didn't resolve the conflict correctly the first time.

> Does bzr have tools to help me with this?

I don't think so.  The problem is that bzr doesn't consider a merge to
be complete until all conflicts are resolved.  There is a bunch of data
in an unresolved merge that just doesn't fit into our model.  Basically,
you don't have a proper working tree if you've got unresolved conflicts.

The obvious issue is the BASE, THIS and OTHER files, but another issue
is the list of conflicts indicating file paths.

Merging is the process of resolving the conflicting values between two
trees.  Where this can't be done automatically, it must be done
manually.  That's where you come in.  So you can see bzr considers the
merge incomplete until the conflicts are resolved.

To take an example of filenames, if I rename foo to bar, and you rename
it to baz, then at merge time, you'll get a filename conflict.  Until
the conflict has been resolved, the file has two potential names, but
neither is obviously better than the other.  Yes, it will have a name on
disk, but that's not really its name.

If we did follow your approach, we'd have to decide
1. which revision gets designated as the merge
2. what do we do with the conflict metadata
3. what do we do with the conflict files
4. what should we do when checking out a revision with conflicts
5. what should we do when merging a revision with conflicts

This would require a new repository model, hence a new repository
format.  Maybe it's the right thing to do, but I'm not convinced yet.

Alternatively, it wouldn't be too hard to implement "diff -r merged:" as
a way of comparing the tree to its state immediately after the merge
completed.  That would give you a way to see what changes you had done
as part of merge resolution.

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

iEYEARECAAYFAksqvtgACgkQ0F+nu1YWqI3qVgCeIVQngK1APBaeb8aQ0DQNWiwI
yCEAn1EvzfWvbP+Cn244DLRO8dbXeLwa
=G5wk
-----END PGP SIGNATURE-----