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

[Rob Schoening]

Also speaking as a user, it seems to me that the real use-case that drives this feature is simply not transmitting "ancient" history in cases where the user is unlikely to ever want it.  The common use case consists of the the guy who is not a monotone expert and wants to check out the head of a given branch but doesn't understand why he needs to download 100s of megabytes of data to do so. 

 

That's a little different than allowing the user to specify exactly how much of a partial pull to make.

 

Rather than make this feature pull-er specified, would it be possible (offline) to employ a checkpoint/archive approach on the part of the developers committing work?  At the far extreme, one can do this today, by simply abandoning the history and creating an entirely new repository consisting of the current heads.  Before you laugh too hard, remember that Linus did exactly this when he moved to Git.  

 

I can think of lots of (vastly improved) variations of this theme that would be entirely sufficient to 95% of users by eliminating the "why do I have to download 100s of megabytes of history?" barrier.

 

But I suppose one person's "elegant" is another person's "clunky"....

 

RS 

 

On 5/30/07, Nuno Lucas <address@hidden> wrote:

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


_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel