monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)


From: Daniel Carosone
Subject: Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)
Date: Thu, 24 Aug 2006 11:19:33 +1000
User-agent: Mutt/1.5.12-2006-07-14

On Wed, Aug 23, 2006 at 08:47:55PM +0200, Lapo Luchini wrote:
> > cvssync and cvs_import do not mix (yet) since cvs_import does not
> > remember the corresponding cvs revisions for each file.
> I think adding a certificate with the corresponding CVS revision would
> be a *good thing* whether one wishes to update the import or not: it
> probably occupies very little in the DB and helps reply to questions
> like "what revision contains file xyz version 1.254?".
> I guess the main problem is that certificates are per-revision and not
> per-file, so yet another "blob" of data to be parsed would be needed
> (with similar speed issues as "annotate" has, I guess).

I think I recall suggesting previously that this information might
well be stored in CVS/Entries files within the monotone repository.

This way, you can basically use a monotone checkout of an imported cvs
revision as a CVS revision. As well as helping users switch, this
probably helps testing that the import worked correctly, too.

> > cvssync is under complete redesign at the moment. It got _much_
> > faster and cleaner in this process but does not fully work, yet
> > (Initial import already works). Stay tuned. [If you only need
> > incremental import that should be possible within this week, again]
> >
> I look forward trying it as soon as you give a thumb-up ;-)

me too.  I can't really help development much, but if there's any way
encouragement will make a difference, let me know.

I can help testing. I'm currently running a cvs_import of the NetBSD
repository..  it's getting further than previous attempts (it hasn't
died yet after a week or so of running, and 150k+ revisions) but it
sure takes a while.

It's also rather slow to use the resulting db; a pkgsrc import
generated 100k revisions and operations like 'heads' take rather
longer than would be desired.  The performance work being done
elsewhere shows encouraging promise here, and these are two good
things that will go well together when they're both done.

> "There is an important limitation, though. This method doesn't
> presently try to attach branches to their parents, either on the
> mainline or on other branches, instead each CVS branch gets its own
> separate linear history in the resulting monotone db."
>
> Does it still apply to cvs_import? Does it apply to cvs_sync (and/or
> will apply to your "complete redesign"?)

I wrote that, and it does still apply to mainline versions/releases.
I'm pretty sure I also wrote about the branch-reconstruction branch
right nearby, feel free to make it clearer and avoid further confusion
if the page needs it.  A link to the relevant #heading in the branch
statuses page might be good.

--
Dan.

Attachment: pgpWtPyYmkCRN.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]