[Monotone-devel] conflict resolution commands

[Stephen Leake]

Here's what I'm thinking of implementing for a command line interface
for specifying conflict resolutions. There's a new command group
'conflicts', in group 'tree'.

conflicts [--conflicts=<file>] store <rev> <rev> 
    run automate show_conflicts, store result in file.
    file defaults to _MTN/conflicts.

conflicts [--conflicts=<file>] show_first
    shows first unresolved conflict and possible resolutions.

conflicts [--conflicts=<file>] resolve_first <resolution>
    set resolution for first unresolved conflict.

conflicts clean
    delete _MTN/conflicts, _MTN/resolutions/* if present.


An example session would be (leaving out the 'mtn' from each command):

merge
    -- gives conflicts.

conflicts store <left> <right>
    -- rev ids copied from merge output, or use selectors.
    -- content conflicts that can be handled by the internal merger
    -- have resolutions of 'resolved_internal' at this point.
 
conflicts show_first
    -- decide how to handle it.
    -- if resolution requires a user-merged file, use your favorite
    -- merger now, store result in _MTN/resolutions/*, or anywhere.

conflicts resolve_first <resolution>
    -- template of appropriate <resolution> is given by show_first;
    -- copy, paste, edit it here.

-- repeat show_first, resolve_first until done.

merge --resolve-conflicts-file=_MTN/conflicts
    -- success!


Comments?

There seems to be a convention that command names use underscores,
while options use dashes; is that correct/desired?

'resolve_first' could get fancy; for example, it could run
try_user_merge for a 'resolved_user' resolution that is missing the
file, and save the result in _MTN/resolutions/*. But it would be
simpler to just let the user do that manually.

Allowing the user to specify an alternate conflicts file allows
alternate work flows. For example, working on propagating two
different branches to trunk at the same time; you could make sure the
conflict resolutions are compatible.

-- 
-- Stephe