[Top][All Lists]

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

Re: [Gnu-arch-users] Re: archive storage format comments on the size

From: Andrea Arcangeli
Subject: Re: [Gnu-arch-users] Re: archive storage format comments on the size
Date: Tue, 30 Sep 2003 18:36:44 +0200
User-agent: Mutt/1.4.1i

On Tue, Sep 30, 2003 at 08:50:20AM -0700, Tom Lord wrote:
>     > From: Andrea Arcangeli <address@hidden>
>     Miles:
>     >> Cached revisions don't work very well with extremely large source 
> trees.
>     > yes, the major problem is that they don't cache locally the granular
>     > patchsets in the local machine. 
>     > You lose information locally, if you fetch from the cacherev. 
> Nonsense.  

nosense? do you realize I need the equivaltent of cvsps probably as the
biggest feature of using an SCM in a big project where staying uptodate
with the parallel development is non trivial?

without all the granular patchsets I lose _all_ the relevant information
locally. I need to fetch granular patchsets _not_ cachedrev that don't
carry all the info but just a cache of the working dir (not a cache of
the archive patchsets that you can't compress well if you leave them

Frankly I'm pretty satisfied with the cvsps and kernel CVS. rsynching
the cvs tree lose zero info and it's very efficient. The archive is
compact 450M of repository with 12000 patchsets, and 250M for the
working dir. cvsps is immediate in looking back 2 years in the past. I
don't think you're used to big projects where you often need to look a
patchset of 2 years back to see the log comment to figure out why it
happened. Sure if you don't care to look back, cacherev are fine, but if
you don't care to look back, you probably don't need much a SCM in the
first place. The archive-mirror --cached-tags is useless to me, I always
need to use --no-cached or there's no way I can dream of using a cvsps
equivalent (at a reasonable speed I mean).

The cachedrev have nothing to do with the superpatchsets. The cachedrevs
for my usage makes sense only to be used locally as a temporary cache to
boost the checkout. And I'm going to use hardlinked rev libs anyways
locally so I doubt I'll ever use cachedrevs.

the superpatchset is absolutely loss-lessy and they compact the archive
of a number of times at the same time (the opposite of a cachedrev). The
loss-lessy and compacting (for disk space and network) behaviour is the
main property of the superpatchset.

What's the nosense?

Andrea - If you prefer relying on open source software, check these links:

reply via email to

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