Re: [Monotone-devel] Workspace merge?

[Stephen Leake]

"Zack Weinberg" <address@hidden> writes:


>> > > 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
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>

-- 
-- Stephe