Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon

[Nathaniel Smith]

On Fri, May 25, 2007 at 07:41:10AM -0500, Timothy Brownawell wrote:
> I think there are really only problems with *generating* revisions with
> multiple ancestors; the only reason we can't have them in history is
> because we chose to have the sanity checking not allow it.

Generating revisions with multiple ancestors is trivial -- you take
your child roster, you pick your parent rosters, you call make_cset as
many times as necessary.

Off the top of my head, the code to generate a new roster given a
parentage and a revision is hard-coded to only handle the 0, 1, or 2
parent cases -- in particular I was not feeling smart enough to make
the node unification stuff work.  (All the messy logic that knows how
to infer that if there was an add_file in one cset but not in the
other, then really no file was added at all, just the side with the
add_file didn't happen to have seen this file before.  I'm not
actually sure how smart we are to be phrasing revisions in this way,
i.e., as a bunch of independent csets that are actually not
independent at all and with a bunch of complex logic needed to figure
out how the independence fail.  This representational choice is also
what kills us in the case someone brought up on the list a while ago,
where keeping an integration branch combining two other long-running
branches becomes prohibitively expensive, because of all the redundant
information in every propagate roster.  Not that I really want to
have another round of discussion on changing the revision format, but
it's worth being aware that that's pretty much the one problem we've
found with the latest generation of revisions.)

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein