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

[Nuno Lucas]

On 5/31/07, Markus Schiltknecht <address@hidden> wrote:
> Nuno Lucas wrote:
> > 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.

I don't intend to support anyone here, as my knowledge about the
subject doesn't allow me such. Only trying to hand over some questions
that might enlighten the subject to the ones who do.

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

Well I think I should be ok if I could still checkout the previous
pulled version. The one thing I believe should not happen is if by a
recent partial pull I suddenly loose access to that previous
revisions.

The fact there is a disconnected gap between them seems ok (and maybe
I can make a partial pull that connects the nodes later).

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

It seems to me monotone should allow to maintain those disconnected
revisions, for the reason I said earlier.

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

This is unlikely, and assumes I will be using 3rd party repositories
that actually use branch heads to mark versions and not simple tags on
a single branch (like CVS).

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

A reason to use monotone for this is when I want to follow some
"experimental" feature of some library. For example, I'm using the
experimental virtual tables API of SQLite in my application.

My application will be tied to that version, because the API may (and
probably will) change  in future versions, so I need to have access to
that version for as long as I need access to my application version at
the time.

I could have just included the sqlite code in the application code,
but I may have reasons to not do it, some probably just aesthetic, and
others maybe having to do with clear separation from proprietary code.


Best regards,
~Nuno Lucas


> 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