Re: [Monotone-devel] Workspace merge?

[William Uther]

On 11/07/2007, at 9:59 PM, Zack Weinberg wrote:

> On 7/11/07, William Uther <address@hidden> wrote:
> >    What's happening with the net.venge.monotone.workspace-merge*
> > branches?  Do any work?  Which are up-to-date?
>
> All those branches are either thoroughly dead or merged to mainline  
> already :-)

Okie.  So when I merge my suspend changes next week, I'll suspend  
them :).

> No work has been done since the summit.  The present state of play is,
> you can do 'mtn merge_into_workspace <revision>' which will merge
> <revision> with the current workspace's parent (I forget what happens
> if there are local changes; I think it errors out) and dump the result
> into the workspace.  You can mess with that as you like and commit it
> once you're happy.

Okie - This also needs to be added to the docs.

> However, conflict resolution is just like 'mtn merge' -- if there are
> file-content conflicts, you have to resolve them immediately, and if
> there are name conflicts it errors out.

Ahh.  Ok.

> >    What is still required to make it possible to merge in a  
> > workspace?
>
> I'm hoping to work on this some this summer, but I'd be very glad of
> help.  The next step is to write code that can take an arbitrary
> conflicted roster_merge_result (see roster_merge.cc) and serialize it
> into _MTN/conflicts (or some such file);

Hrm.  For a first pass, I'd only allow is_clean_except_for_content()  
stuff to
be left in the workspace.  If there are file-name conflicts then you  
must
resolve them at merge time.  Actually, I'm not really sure there is  
another
good way to do this as you need to represent things in the file system.

That restriction means you only need to handle file_content_conflicts.
My next thought is...  can we actually leave the conflict marker in the
roster instead of a new file in the options/ directory?
(Quick terminology check: roster == list of files in a revision.   
Right?  I
don't think I should be using the term manifest or "revision from  
revision.hh" here.)

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

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.

Once there are no conflicted files you could commit the new revision.

In future we could get more adventurous and allow the merge command  
to commit
revisions with conflicts in their rosters (although I'd keep the  
restriction that
users cannot commit conflicted files).  That change would allow the  
use of
deterministic mark-merge :).

If there are only file content conflicts then those revisions can be  
checked out.  The
result would be the same as above.  Revisions with more than  
file_content conflicts
could not be checked out.

I suspect you'd want some efficient way of determining the conflict  
state of a revision:
general conflicts, file-content conflicts only, and conflict free.   
You'd probably want
a way of ignoring revisions with conflicts in 'mtn update' for example.

OOooo - If you allow conflicted revisions in the repository like  
this, then there no
reason for a multi-parent workspace any more.  You merge, put the  
merged rev in the
repository, then you check it out and fix the conflicts.  The  
repository starts to
look very like the revision graph in the deterministic mark merge  
write-up.

Sigh.  Monotone still wouldn't have fully associative and commutative  
merges though.  Even though deterministic mark merge has those  
properties, the way monotone chains history would break them.

> also to fix up the conflicted
> roster to be "sane" (per check_sane()) and make all the conflicted
> files visible in the workspace.  Then we'll have to go fix all the UI
> that doesn't know how to deal with a workspace in that state, and
> write a new resolution UI.

I'm not 100% sure what a 'sane' revision is.  Is that equivalent to  
saying it only has
file content conflicts?  If so, then that makes perfect sense.

The UI would be as above (which is basically the subversion UI, which  
I think works pretty well).  The only difference being that  
subversion is able to use revision IDs in the filenames and it is  
clear which is the ancestor.  We'd need to be explicit there.

Note that I haven't proposed a UI for non-file-content conflicts.   
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).

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

Anyway, is there a good place to look for docs on rosters (assuming  
my terminology is right)?
In particular, where and how are "insane" rosters marked?  Could I  
just commit one of these?  Can I get a list of conflicts (as per  
roster_merge.hh) from an "insane" roster?

Cheers,

Will         :-}