[Top][All Lists]
[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
signature.asc
Description: OpenPGP digital signature
- [Monotone-devel] big repositories inconveniences (partial pull?), Lapo Luchini, 2006/08/23
- [Monotone-devel] Re: big repositories inconveniences (partial pull?), Koen Kooi, 2006/08/23
- Re: [Monotone-devel] big repositories inconveniences (partial pull?),
Christof Petig <=
- [Monotone-devel] Re: big repositories inconveniences (partial pull?), Lapo Luchini, 2006/08/23
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Nathaniel Smith, 2006/08/23
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Markus Schiltknecht, 2006/08/24
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Markus Schiltknecht, 2006/08/24
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Nathaniel Smith, 2006/08/24
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Markus Schiltknecht, 2006/08/24
- cvs branch reconstruction (was Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)), Nathaniel Smith, 2006/08/24
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Christof Petig, 2006/08/25
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Markus Schiltknecht, 2006/08/25
- Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?), Christof Petig, 2006/08/25