Re: [Monotone-devel] resolving name conflicts; implementation issues

[Stephen Leake]

I've run across a problem with the 'update' command.

I've checked in a revision on nvm.automate_show_conflict
(598003d09dcb8002a8fd2d55d56c6d4ac0e243e1) that implements sutures
well enough to handle the following scenario (see
tests/resolve_duplicate_name_conflict):

                  o
                 / \
                a   b
               / \ /
              c   d
               \ /
                g
                

'o' is the base revision. In 'a' and 'b', Abe and Beth each add a
file with the same name:

     checkout.sh
         the user intent is that there be one file with that name;
         the contents should be merged.

in 'd', Jim resolves duplicate name conflict by suturing checkout.sh.

in 'c', Abe edits checkout.sh

in 'g', Abe merges his changes with Jim's merge.


However, when Abe runs 'update' after merging to 'g', it reports
'content changes to the file checkout.sh will be lost'. That's because
the merge algorithm used by 'update' does not understand sutures.

My most recent commit fixes this problem, but causes others.

The update algorithm used on the nvm mainline constructs a 'synthetic'
revision graph when updating:

update -r rev 

    base
   /    \
rev    work
  \    /
   new_work

It does _not_ use the cached marking map for base or rev. However, all
information about suturing is stored in the marking map, so this
algorithm cannot handle suturing. Let's call this algorithm the
'synthetic tree algorithm'.

My fix does use the cached marking maps, and does not construct a
synthetic tree; it uses the real revision tree, treating the current
workspace as a leaf revision to be merged. Let's call this algorithm
the 'full tree algorithm'. For the scenario above, it has the
desired effect; it understands sutures, and issues no warnings.

However, there are other uses of 'update' for which synthetic tree is
the right algorithm.

The simplest is when switching branches; my implementation checks for
that, and uses the sythetic tree algorithm; see cmd_merge.cc CMD(update).

Another case is switching to a different head on the current branch, or
going back to a previous revision on the current branch.

To make things clearer, let me introduce some hypothetical new
commands:

'switch_to rev' - (in effect) deletes the current workspace (or at
    least all the known files), and checks out revision 'rev'. This is
    similar to 'revert_to' in the lua tests.

'record_cset' - records the changeset from base to working

'apply_cset' - applys the cset saved by 'record_cset' to the current
    workspace. 

Then the effect of the 'synthetic tree update' is;

    record_cset; switch_to rev; apply_cset

The real algorithm is more complicated, due to potential conflicts and
other issues.

The effect of the 'full tree update' is:

    commit; merge; switch_to head

except the commit is not actually done; the merge is done in the
workspace.

In normal development flow, the 'full tree update' is what we want; in
fact, it is better if people always commit before updating.

But the other use cases are important as well. If we use the full tree
algorithm there, the workspace is in fact unchanged, but the base
revision is switched, and the changeset from the new base revision to
the unchanged workspace is recorded in _MTN/revision. Not the desired
result.

So I think there needs to be either a new command or a new option on
update to distinguish the two cases.

Or there may be a way to make the synthetic tree algorithm understand
sutures. But I don't think that's the best approach.

Hmm. Maybe the presence of an explicit revision in the update command
line is enough to decide which algorithm to choose; if no explicit
rev, use full tree, otherwise use synthetic tree. I'll try that.

-- 
-- Stephe