Re: [Monotone-devel] How to join identical branches?

[Stephen Leake]

Markus Schiltknecht <address@hidden> writes:

> Hi,
>
> Stephen Leake wrote:
>> I'd like to change monotone to offer to merge the conflicting files;
>> that would clearly work in this case, and is The Right Thing in the
>> cases I have run into as well. 
>
> Hm.. conflicting files have different node ids, so they certainly
> don't have a common ancestor. 

Yes, that's why monotone can't just use it's normal merge algorithm.
By 'merge', I mean 'use internal line merger or the external merger'.

> A manual merge should be doable anyway, 

Right; I'd like monotone to offer to help start that, by calling the
normal external merger on the two files.

> but the resulting file will have to carry on one or the other
> existing node id. This might affect future merges. Also consider
> what to do with the other node id. If you simply drop that by
> deleting the file (in favor of the other one), any future changes to
> it, which should have been added to the merged file, will get lost,
> due to die die die.

The use case I am concerned with here is that there really should be
only one file, named "foo"; Beth and Abe just happen to realize that
separately, and commit slightly different versions of it.

There can be lost changes if Beth resolves the conflict by dropping
Abe's version, but Abe makes more changes before syncing. In that
case, monotone issues a warning when Abe syncs and merges his changed
"foo" with Beth's drop of it:

mtn: 2 heads on branch 'testbranch'
mtn: [left]  587b23da811ee8998263ee61cfc3d99411d2584e
mtn: [right] 85420004b753e4dc93bfba9ad2f2243395e025b7
mtn: warning: Content changes to the file 'testfile'
mtn: warning: will be ignored during this merge as the file has been
mtn: warning: removed on one side of the merge.  Affected revisions include:
mtn: warning: Revision: 85420004b753e4dc93bfba9ad2f2243395e025b7
mtn: [merged] 3d6188cf266a7e45ef2a6d01262d0aa05478f654
mtn: note: your workspaces have not been updated
 
To recover, Abe must manually check out his committed revision, and
merge it with Beth's. 

Note that it is actually difficult for Beth to drop Abe's revision;
she first has to check out his head explicitly, then drop. It is
easier, and just as correct, for her to drop her version. In that
case, there cannot be future changes to the dropped version. So
getting to the case where changes are lost is difficult.

Hmm. If there is a third developer involved, they could be making
changes on Beth's version, that would eventually be lost with a
warning. In that case, I'd like an option to promote that warning to
an error.

I don't see any other solution to this case; one node must be dropped.

Another use-case that gives the same non-content conflict is when the
two files should have different names, but accidentally have the same
name. Then the solution is to rename one or both. Beth can rename
hers, and then rename Abe's after the merge, if necessary.

If one of the nodes is a directory, the only solution is rename.

Are there other cases? 

I would like to automate the process for the "should be one file" case.

When a non-content conflict is detected, I would like monotone to do
the following:

1) Give a prompt like:

    "Non-content conflict detected. Merge the contents and drop one?"

2) If the user answers "yes", use the internal or external merger to
   merge the file contents into the remote file, then drop the local
   one, and proceed.

   Here "local" means "in the current workspace"; is that always
   "right"?

3) If the user answers "no", stop with an error (as it now does). Or
   offer to rename the files.

Perhaps that is a more complex UI than mtn typically offers. I'll have
to think about doing this in Emacs DVC instead.

Another solution would be to provide a new option --merge-drop-right for
merge. Then the flow would be:

merge
    -- fails with one or more non-content conflicts

rename as appropriate to resolve some conflicts

merge --merge-drop-right
    -- resolves remaining non-content conflicts as described above, succeeds

That is a simpler user interface, since it doesn't involve prompting.
However, it will be slower, since it involves two passes.

A new "automate merge" would allow an external UI to do the right
thing in one pass; that would be the best solution.

> Thus, I think it's currently handled quite well, by noticing the user
> of the conflict. 

It would help if how to handle this error message was discussed in the
manual. Perhaps the error message could refer to the proper section of
the manual.

There is currently a section "Advanced Uses | Workspace Collisions"; we
could add "Advanced Uses | Non-content Conflicts". I can do that, once
I get confirmation that I understand the issues correctly.

-- 
-- Stephe