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

[Markus Schiltknecht]

Hi,

Nuno Lucas wrote:
> 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?

Thank you for supporting my idea, but I can see Nathaniel's point very 
well (which hurts somewhat, because I though I had a clever idea - oh 
well...). Now, I'd like to figure out if gaps are really needed or not, 
before coding something nobody ever needs.

So, if we don't implement gaps, but require monotone to have exactly 
*one* contiguous window of the repository's history, the answer would 
be: yes, monotone would probably forget about the other partial pull.

And question which follows is: do you care?

> 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?

No, monotone would simply drop unneeded revisions. Please note, that not 
the age of a revision is important, but it's depth from the head(s). 
Nathaniel's example is probably somewhat misleading in that aspect.

So it depends on what exactly you need from your 3rd party library. As 
long as you only need the heads of any of the branches of your 3rd party 
library, you are probably fine without gaps.

Only if you need exactly tags Rev1996, Rev2001, Rev2005 and the head of 
the very same branch, you would have to create multiple monotone 
databases without gaps.

I still like gaps, because they make monotone more flexible by removing 
an unexpected and seemingly random limitation for the user. But I know 
that implementing them completely is quite some work. Implementing only 
what's needed for partial pull is much less work (i.e. disallow 'mtn 
serve' from partial repositories, which is another unexpected 
limitation, IMO).

As partial pull can be a subset of what's needed for gaps, I currently 
think it's best to start implementing partial pull, while still keeping 
the way to a full 'gaps' implementation open.

> Just food for thought from an user.

Yup, thanks for your inputs.

Regards

Markus