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

[Markus Schiltknecht]

Hello Stephen,

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

Okay, that's a reasonable goal, IMO.

> > 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

Oh, cool. I didn't know monotone issues a warning in that case.

> To recover, Abe must manually check out his committed revision, and
> merge it with Beth's. 

This is about equally painful as having to rename a file before being 
able to merge. But it occurs much less frequently. Only if the dropped 
node_id gets changes which also need to be merged. So yes, this might be 
beneficial for the situation described above.

> Note that it is actually difficult for Beth to drop Abe's revision;

The revision? You mean to drop the file, right?

> she first has to check out his head explicitly, then drop. It is
> easier, and just as correct, for her to drop her version.

Well, yeah, but you have to figure that out first. And maybe Abe has 
also committed changes she doesn't want to disappear.

> In that
> case, there cannot be future changes to the dropped version.

That's certainly wrong. We are in a distributed system, it happens quite 
frequently, that Chuck syncs and then Abe merges. Even if Abe now syncs 
to a central repository right away, Chuck might commit changes to the 
file which Abe dropped as part of the merge.

> So
> getting to the case where changes are lost is difficult.

Not more difficult, than committing the "same" file (by filename) - 
which is how that whole problem arises in the first place.

> 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.

Uh.. that would involve tracking the reason for deletion (dropping) 
files. Because normally, you want the "deletion" of a file to be 
propagated across merges. Somehow, you would then have to be able to 
disambiguate between manually dropped files and files dropped due to a 
resolved non-content conflict.

Not sure how much that affects file undeletion, but it certainly has a 
lot to do with die die die.

> 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.

Huh? The real solution to that would be support for copying file, no? In 
a way, it is similar, yes, because copying involves duplicating node ids 
for two distinct filenames. While the above involves reducing node ids 
to one filename.

> 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"?

I wouldn't use local and remote here, it's rather confusing. Because 
monotone doesn't differentiate between revisions created locally and 
remotely: both end up in the database, and both are needed for the merge.

Also note, that the merge isn't associated with a workspace, but only 
with the database. This is why you need to manually do an "update" after 
the merge. IMO this should absolutely stay so, because it's a nice 
separation of concerns.

> 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.

I don't know Emacs DVC, but that sounds like a good option.

> 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.

I also like that better than prompting. I don't consider speed or having 
to type a little more to be real draw-backs here.

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

Well, do we really need that there? Isn't it better to simplify 
automatic creation of revisions (without requiring a workspace) and let 
automate-users (i.e. the GUI programs) create a helper revision before 
the merge? That would help a lot of other use cases as well.

> > 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.

Agreed.

> 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.

That would be great, yeah. I'm gladly offering help and review for that.

Regards

Markus