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

[Nuno Lucas]

On 5/30/07, Nathaniel Smith <address@hidden> wrote:
> On Tue, May 29, 2007 at 02:42:03PM +0200, Markus Schiltknecht wrote:
[...]
> They may wish to at some point do
>   mtn pull --restrict-last 2000
> to fetch more history.  This asks the server what the new horizon
> should be, moves the horizon there, and fetches intermediate stuff.
> (It also effectively forces a full regenerate_rosters.)
[...]
> > My reasoning was: if we are going to implement sentinels for gaps
> > between a horizon and the root, why not do it right and add support for
> > gaps of any range? It's only marginally more work, while being a much
> > more general solution.
>
> Generality is only good if it is for a purpose.  I'd still like to see
> some use case for why I would want to have history from 1990-1992,
> 2000-2001, and 2005-present together in a database.

As an interested but not actually a monotone developer, I'm an
excellent use-case for this.
It's normal to pull from n.v.m from time to time, but can be months (I
think last time was over a year) between.

Suppose I already have a partial pull 2 years from now. What would
happen if 10k revisions had been committed and I do a partial pull
again for the last 1000?

Would monotone forget about the other partial pull? Would it error out?

It's also very common to fetch the last revisions of 3rd. party libs I
use. I only want the current of the time, and can be years before I do
it again. As those other libs don't use monotone I have no problem,
but what if they did? Would I need to use a new db every time?

Just food for thought from an user.


Best regards,
~Nuno Lucas