[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 11:41:34AM -0400, Miles Bader wrote:
> > None the less, avoiding the overhead of applying lots of little changesets 
> > is
> > still often desirable, which is the reason for the other thread on summary
> > deltas.
> 
> agreed, but I prefer the cache to happen locally or I would lose
> information during network transfer.

That's not right. You don't lose any information using or not cached 
revision or cached libraries:

-cached revisions
 * are stored in the archive
 * can be added (tla cacherev) or deleted (tla uncacherev)
 * are not transferred in mirrors or gets of your archive
 * improve performance of gets (as they are a tree revision tar.gz'ed

-revision libraries
 * are stored in your filesystem, not the archive
 * are created in cascade backwards up to base-0 using hardlinks for 
   shared files
 * are even better for performance of gets are they are uncompressed

> the local caches are fine, they're temporary data. After I finished
> working on it I can delete all the caches (possibly loaded in /dev/shm
> as Pau said ;), all the real info is stored in the archive (and the
> superpatchsets helps exactly in keeping the archive as compact as
> possible by allowing a x20 compression instead of the current x2
> compression of the tar.gz).

Superpatchsets, or summary deltas as discussed in another thread, are on
its way, but it's not as easy as it sounds if you want to keep things easy
and still only need dumb servers. Let's discuss it on the other thread.

In your case I envision something like this:
-build a cachedrev every 100 patches (just look for the optimal figure)
-build revision libraries in /dev/shm via a crontab so that all your gets 
 of new trees are immediate.
-if you feel like, keep the libraries in a permanent filesystem, but I 
 don't see it as a must.
-use cp -al to create the new branches trees, as discussed

Pau