gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Caching (was: GNU Arch review - am I accurate?)


From: Stefan Monnier
Subject: Re: [Gnu-arch-users] Caching (was: GNU Arch review - am I accurate?)
Date: 14 Mar 2004 16:16:39 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

> For performance, revision libraries do the trick. Tla does not
> automaticaly prune them -- it has to be done by an independent script
> (perhaps from cron).

It could be done by tla as well.
Admittedly, OSes should have the notion of "disposable files" so you could
use all the disk space with revlibs and they'd be deleted by the OS when
more diskspace is needed.  But in the mean time, it'd be nice to have tla
do the pruning itself.

> For offline work, it may never be automatic, because you must tell it
> what you want to have cached for offline work. Archive mirroring will do
> the trick.

There's no reason why it can't be as automatic as revlib: just cache
whatever has been fetched from the network.

>> Mirrors are not at all automatic.  A far cry from a "cache".

> They can be made automatic for backup purpose by putting push-mirror in
> a hook.

Huh?  What hook?  What mirror?  Last I tried you can't modify a mirror, so
there's no hook to use there.  As for the main archive, you generally don't
have write access to it, so you can't add a hook there.
But in any case, the problem is mostly the setting up of mirrors which no
amount of push-mirror will automate for you.  Revlibs are much better here.
Furthermore, mirrors only cache "the whole thing or nothing".

> For offline work they can't really be automatic, because you
> need to say on what you want to work. And for caching revision libraries
> are usualy better.

A good way to say "I need this data" is to access it.  So having
transparent caching makes perfect sense for offline work as well.
I do that all the time with revlibs: I never explicitly add something to
the revlib, instead I just do `tla changes' to make sure the base revision
is in the revlib.

>> And also offline work.  That's closer but:
>> - You have to set it up manually (which is not that bad since it's only
>> done once, but still: it should be setup automatically with a sensible
>> default).
> It's a bit hard -- you have to say where they should be put.

What's hard about choosing a sensible default?

>> - It does not cache patches.
> Sure it DOES.

My definition of caching is "transparently keeping copies nearby".
Patches are never cached in this sense.  You can manually copy them nearby,
but that's just mirroring, not caching.

>> - It does not cache some other meta data (not sure which, but when I do
>> `tla build-config ...tla-1.2' tla somehow needs to access the network
>> and check some patches's sigs even when all the trees's revisions are
>> in the revlib).

> Does the config only contain _revision_, or does it contain _versions_
> too?

I wouldn't know.  I just want to rebuild Tom's tla-1.2 and know nothing of
how he organizes his thing.

> In the second case, it needs to look which is the latest revision...

Yes, although I don't see why it should need to check any signature since
the revision is ends up using is already in the revlib.  I thought
signatures where only added to patches, not to "the current list of patches
of this version".  But I admit ignorance here.


        Stefan




reply via email to

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