Re: [Monotone-devel] Workspace merge?

[Zack Weinberg]

On 7/12/07, William Uther <address@hidden> wrote:
> 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?
...
> > 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.

I don't want to put it in the official manual in its present state,
because it's little use as is and may change significantly before it's
done.  You yourself propose some pretty radical changes ...

That said, it couldn't hurt to put more documentation of the present
state, and the roadmap to full functionality, on the wiki.  I don't
have time to mess with it until next week, though.

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

I would actually say it is easier to do it the other way around.
There are many different kinds of name conflicts, but for each of
them, I believe it's possible to recover roster sanity by tacking a
canned sequence of renames onto each change set involved.  The
existing namespace manipulation commands can then be used to resolve
the conflicts.

By contrast, file content conflicts require you to come up with
an entirely new mechanism for making the roster sane.  We certainly
want all the files you listed to show up in the workspace, but which
of them get to be 'known' and which are just dumped there?

Tangentially, I want conflict marker generation to be left to a lua hook.

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

Roster means one of the data structures defined in roster.{cc,hh} and
stored in the 'rosters' and 'roster_deltas' tables in the database.
There is one roster per revision, and its content is a structured list
of files in that revision, plus mark-merge metadata, as I understand
it.  The 'revision' structure (revision.{cc,hh}; 'revisions' and
'revision_ancestry' tables) is concerned with ancestry, not content.

Manifests are older, and I believe now used only in the netsync
protocol; they did the same job as rosters, but did not carry all of
the same information.

A roster is "sane" if and only if the check_sane() method on the
relevant roster_t object does not throw an invariant failure.  A
roster resulting from an unclean merge is never sane; there are other
ways a roster can become insane, but I think they would all be bugs.
There is almost nothing you can do with an insane roster; check_sane()
is called by most roster operations.  In particular, it cannot be
committed.

There is also check_sane_against(), which has to do with markings; I
confess I do not understand why 'marking_map' objects are separate
from 'roster_t' objects.

I would be very reluctant to put the conflict marker in the roster.
That data structure is complicated enough.  I'd rather see a separate
serialization of the conflict list in the roster_merge_result,
indicating which changes to the workspace roster have been faked up to
remove conflicts.

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

Absolutely.

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

I would really rather not go there yet, but don't let me stop you
experimenting.

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

Yup.

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

There are long comments in the source files.  You should read
roster.hh, roster.cc, roster_merge.hh, and roster_merge.cc in their
entirety.

zw