Re: [Monotone-devel] resolving name conflicts; file suturing vs drop

[Stephen Leake]

Markus Schiltknecht <address@hidden> writes:

> William Uther wrote:
>
>> Hrm.  If you have sutures conflict with deletes, then you're making
>> the user choose what happens every time that comes up in a merge.
>> You're relying on the fact that that wouldn't happen very often.
>
> Correct. But besides resolving the 'same-file-added' non-content
> conflicts, which is the use case which inspired this proposal, I can't
> think of many other use cases for suturing. Can you?

A user could use it to unify two files. For example, in the inverse of
the "thermostat" use case; Abe and Beth initially write
thermostat-honeywell.c and thermostat-westinghouse.c, but later (after
much history is accumulated) realize there is enough similarity to
make it worth having only one file. So they suture them together into
thermostat.c.

This is essentially a variant of "same-file-added", but with a
different user intent. It requires a new user command:

mtn suture <file_1> <file_2>

not a 'merge --resolve_conflicts'.

Although it could be accomplished by renaming both files to the same
name in separate heads, then merging with --resolve_conflicts. But
that's messy!

Currently to implement this we have to drop one file, losing its history.

There are several files in the current tests that mention suturing: 

./(normal)_netsync_on_partially_unrelated_revisions/__driver__.lua:5:-- This 
test relies on file-suturing
./add_workspace_commit_in_another/__driver__.lua:4:-- This test relies on 
file-suturing
./annotate_file_added_on_different_forks/__driver__.lua:4:-- This test relies 
on file-suturing
./annotate_file_on_multirooted_branch/__driver__.lua:4:-- This test relies on 
file-suturing
./merge((add_a),_(add_a,_drop_a,_add_a))/__driver__.lua:4:-- This test relies 
on file-suturing
./merging_adds_in_unrelated_revisions/__driver__.lua:4:-- This test relies on 
file-suturing
./merging_an_add_edge/__driver__.lua:4:-- This test relies on file-suturing
./merging_data_in_unrelated_files/__driver__.lua:4:-- This test relies on 
file-suturing
./merging_data_in_unrelated_revisions/__driver__.lua:4:-- This test relies on 
file-suturing
./update_with_pending_add/__driver__.lua:4:-- This test relies on file-suturing

They are all variants on "same-file-added"; some use rename to get the
conflict. Although I don't quite understand the netsync one; netsync
is about copying revisions, not merging them. So I hope that one isn't
really needed. One has a duplicate name for a directory, which we need
to be sure to handle. All of them are currently xfail on a merge that
has the duplicate name conflict.

We should make sure they all work after we get suturing implemented.
But some of them are duplicates, and could be deleted. Or sutured!

> Well, I think the problem basically is, that monotone currently
> prefers dropping over other actions. Maybe one could even argue about
> renaming or editing having to conflict with dropping, because those
> represent conflicting user intentions.

That makes sense. As long as we have a good way to allow the user to
specify how to resolve the conflict. Adding interactive aliveness
queries to the current merge process makes sense. And adding the new
conflict to [automate] show_conflicts and merge --resolve_conflicts
would also work.

-- 
-- Stephe