[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon
From: |
Markus Schiltknecht |
Subject: |
Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon |
Date: |
Thu, 31 May 2007 09:58:39 +0200 |
User-agent: |
Icedove 1.5.0.10 (X11/20070329) |
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
- Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, (continued)
Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Nathaniel Smith, 2007/05/29
- Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Markus Schiltknecht, 2007/05/29
- Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Derek Scherger, 2007/05/29
- Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Nathaniel Smith, 2007/05/30
- Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Nuno Lucas, 2007/05/30
- Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Rob Schoening, 2007/05/30
- Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Nathaniel Smith, 2007/05/31
- Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon,
Markus Schiltknecht <=
- Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Nuno Lucas, 2007/05/31
Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Markus Schiltknecht, 2007/05/31
Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon, Nathaniel Smith, 2007/05/31