Re: [Monotone-devel] Workspace merge?

[Stephen Leake]

"Zack Weinberg" <address@hidden> writes:

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

I would vote for ignoring the "extra" files, and listing the
conflicted one as "known conflicted" in 'automate inventory' in
nvm.basic_io.inventory (which needs to be merged with main soon).

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

Yes, with a default to the CVS style.

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

Ah. So in the info manual in general, we should talk about "rosters",
not "manifests"? I just rewrote the section for 'automate inventory'
in nvm.basic_io.inventory, using the term 'manifests'.

> 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'm not clear how that would interact with 'automate inventory'; that
code gets all of it's information from rosters (I think).

--
-- Stephe