Re: [Monotone-devel] resolving name conflicts; first success

[Stephen Leake]

I have pushed 8e31c7bd779710254b1d0425c0e35bc98598d813 in
nvm.automate_show_conflicts that handles sutured files in rosters and
changesets. There is still much work to do, but this passes the
simplest merge test case; see tests/resolve_duplicate_names_conflict.
So I'm feeling happy :).

I added the following to 'struct node' in rosters.hh:

  std::pair<node_id, node_id> ancestors;
  // new, resurrected: first, second = the_null_node
  // sutured: first = left, second = right
  // copied: first = copy source, second = the_null_node
  // otherwise: first = self, second = the_null_node
  //
  // in workspace rosters, ancestors is always null

I added code to handle this in cset.cc, roster_merge.cc, roster.cc and
elsewhere. There are more places that need work. In particular, there
are new unit tests that need to be written. But I want to make sure
this approach is sound before spending much time on unit tests.

There is a new 'sutured_file' item in the changesets that are stored
in revisions in the database. So I think merging this to main will
require a database flag day; every monotone user sharing a central
database must upgrade at the same time.

Using an old monotone on a revision with a sutured file will throw a
basic_io parser error; it may not be a very clear error message.

There is a format number in the revision data. It is simply hard-coded
to "1" in revision.cc print_insane_revision; there are no comments on
when it should be incremented. Changing it will give a nice error
about upgrading monotone in revision.cc parse_revision; so it probably
should be incremented.

That format number is also in _MTN/revision; it seems like that might
cause problems when upgrading monotone with an existing workspace. It
would be nice if the flag day only involved upgrading mtn, not also
rechecking out all workspaces. I'll try that. The format of the
_MTN/revision file has not changed, nor any of the other _MTN files.

On the other hand, there's a _MTN/format file, with a "2" in it; I
haven't looked for the code that generates that yet.

The next step is to run the current full test suite to see if anything
broke. 

Then implement the more complex test cases we have discussed.

-- 
-- Stephe