monotone-devel
[Top][All Lists]
Advanced

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

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


From: Christof Petig
Subject: Re: [Monotone-devel] big repositories inconveniences (partial pull?)
Date: Wed, 23 Aug 2006 17:24:55 +0200
User-agent: Thunderbird 1.5.0.5 (X11/20060728)

Lapo Luchini schrieb:
> Use case: as some of my latest messages may have lead to think, I'd like
> to "mtn cvs_import" the full FreeBSD /src CVSROOT.
> "du -h" reports 1.8 GiB worth of CVS ",v" files that cvs_import imports
> in a database around 1 GiB in size (my import created a 500+ MiB one and
> a 80 MiB journal, as it didn't finish due to a power outage, I'll try
> again tonite).

I would love to see partial pull within monotone! [I just don't have
time to spent on that feature]

> Using a gigabyte-sized isn't quite the same thing as "hey, all of
> monotone itself is only 50 MiB, just download it and be happy with your
> complete local repository clone", many people would argue that's quite a
> bit too much to ask on developers..?
> 
> Two question:
> 1. how much will be the size of just the main branch? I hope to have an
> answer after I retry the import;
> 2. how to work "more conveniently" with it? one possible idea is
> "partial pull", but of course that leads to various funny issues, like
> "mtn log" quite possibly ending with sentences like "and probably more".
> 
> I also wonder how much difficult would be to have an incremental
> cvs_import (to keep in sync at least in one direction).

Incremental cvs import is what cvssync provides. Partial cvs!-pull is
possible with cvssync.

However:

cvssync and cvs_import do not mix (yet) since cvs_import does not
remember the corresponding cvs revisions for each file.

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]

cvssync was never tested against huge repositories. Ease of design and
bandwidth efficiency were design guidelines not memory efficiency.

   Christof

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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