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

[Pau Aliagas]

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.

Pau