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

[Nathaniel Smith]

On Fri, May 25, 2007 at 10:51:10AM +0200, Markus Schiltknecht wrote:
> I came to think about that single horizon. Why do we limit to only one 
> horizon? That poses the problem, that on subsequent partial-pulls which 
> move the horizon, monotone would have to throw away revision data it has 
> already fetched. That seems wasteful. Can't we have multiple horizons, 
> i.e. gaps of missing revisions?

I assumed that in the normal case, one would do a partial pull to
fetch the last chunk of history, but then only append to that going
forward -- i.e., partial pull databases still grow over time at
exactly the same rate as other databases, they just start out smaller.
That seems like what most users would want, anyway.

Not that this is really relevant to the question of gaps, because
a rolling history window is still a contiguous history window.  I
might not be understanding what you mean.

Anyway, from reading this thread so far, I'm not at all convinced
that gaps are useful, or anything other than heinously complex to
implement and document.  Ordinary single-horizon partial pull is
conceptually straightforward, because all of our code _already_ knows
how to deal with the horizon -- right now the "horizon" is hard-coded
to always be "the root of the graph", but you can handle a lot of
cases by just going through and tweaking all the loops that stop when
they see the magic [] revision, to instead stop when they see a
revision in the magic db.get_horizon() list.  I have no similar
intuition about how to implement gaps; it seems like they'd need a
whole pile of new machinery everywhere.

As for their utility, the most compelling use case seems to be that
they could be used for the "obliterate" case ("the judge said we can't
distribute this code anymore").  Are gaps really the right thing,
though?  I don't have a great intuition here, but it seems to me that
in the cases where you do have to delete such code, it's often stuff
that was around for a while undetected, but restricted to a single
part of the codebase -- so you don't want to delete your entire
history between versions 1.1 and 1.3, you want to delete just that one
file across that range.  And gaps won't help with that anyway.

Am I missing something?

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould