Re: [Monotone-devel] Workspace merge?

[Stephen Leake]

William Uther <address@hidden> writes:

> I'd refuse to check in any revisions with a conflict in their roster.

I can see that as a reasonable first step, but in the long run we
should be able to commit conflicts. Here's a use case:

Abe and Beth are working on the same file, and both commit, resulting
in a conflict. Beth starts resolving the conflict, but discovers she
needs help from Jim. So she commits the partially resolved but still
conflicted file, so Jim can see it and finish the work.

I'm fairly new to monotone, but I've now done a couple of merges, and
I really dislike the "must resolve _all_ conflicts _now_" approach. If
it turns out there is more work than I have time for, the merge
aborts, and I have to repeat all the work the next time I try it.

I guess I could save partially fixed files somewhere, but monotone
should facilitate that.

merge_into_workspace is definitely useful. For one thing, CVS users
are used to it, so it would ease their transition.

> If you have a conflicted file in a roster, it is marked as conflicted
> in the status output.
> You get four copies of the file in your workspace: ancestor, left,
> right, and
> merged-with-conflict-markers (respectively: myfile.ancestor.<rev>,
> myfile.<revL>, myfile.<revR> and myfile).  Once you've fixed the
> conflict, you run
> "mtn resolved" on the file.  It then has its conflict status in the
> roster resolved
> and the three extra files in the workspace are removed.

That sounds excellent.

> Note that I haven't proposed a UI for non-file-content conflicts.

I don't have any experience with these yet; they don't occur in CVS
:).

> There are two options there: i) the merge fails (albeit with better
> messages than currently), or ii) the merge succeeds and has a
> conflict marked in its roster. In case i) you have to fix it by
> checking out one of the parent revisions and moving files so there
> will be no conflict. In case ii) you do the same thing, but
> deterministic mark-merge allows you to do the merge first, then make
> the revision fixing things based on one of the parents and merge it
> in afterwards.
>
> In neither case is there ever a working copy with a non-file-content
> conflict.
>
> I think I prefer option i) - fail early and make the user fix it
> (albeit with helpful
> error messages).

That sounds reasonable.

>> There are also a few commands that haven't been fixed up for a
>> two-parent, no-conflict workspace; I don't remember which ones, but
>> they should be listed on the wiki.
>
> I assume you're referring to this list:
> http://www.venge.net/mtn-wiki/MultiParentWorkspaceFallout
>
> diff is interesting.  The right way is probably to diff against the
> base merge.
> revert similarly.
> update semantics don't seem too hard if there is no diff on a conflicted
> file.  If there is a diff on a conflicted file, then you fail and
> they have to
> commit or revert.
>
> I think I'd solve this by not having multi-parent workspaces, but by
> allowing conflicts in the repository.  :)

That does seem cleaner.

--
-- Stephe