[Top][All Lists]

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

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

From: Pau Aliagas
Subject: [Gnu-arch-users] Re: archive storage format comments on the size
Date: Tue, 30 Sep 2003 16:39:38 +0200 (CEST)

On Tue, 30 Sep 2003, Andrea Arcangeli wrote:

> On Tue, Sep 30, 2003 at 03:07:18PM +0900, Miles Bader wrote:
> > Karel Gardas <address@hidden> writes:
> > > I'm just curious, but isn't cached revision designed exactly to solve this
> > > issue? i.e. loong get with a tons of applied patches...
> > 
> > Cached revisions don't work very well with extremely large source trees.

I agree that they are a bit excessive, but I was proposing to build them 
every 100 patches and deleting the previous ones. It could even be done in 
a fine-tuned crontab, in Andrea's case, as his needs are very special.

He could even setup the library dir in /dev/shm to have all source in RAM!
It's not mandatory to keep it permanently, it's a cache, not the repo. 
Again the cron tab could do it adapted to his needs.

> 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. and the primary repository will grow not shrink
> with the cacherev creation.

That's not like you say. A cached revision is a tar.gz that includes all
the patch-logs, so you don't lose any granularity. You speed up the tla 
get because you untar directly and only apply the patches you are missing.

The only problem is that the tar.gz will be several Mb large, but so will 
be the archive, so it's a clear win. Build a cache revision of each branch 
every N patchs and delete the previous ones; keep a couple around.

The archive will not grow if you delete old cached versions.


reply via email to

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