[Gnu-arch-users] Re: Arch caches

[Aaron Bentley]

Tom Lord wrote:
>     > From: Aaron Bentley <address@hidden>
>
>
>     > >>   address@hidden/foo--bar--1.0--patch-53/full-tree.tar.gz
>
>     > Say we used the above to represent cacherevs and imports.  We'd also want
>
>     > address@hidden/foo--bar--1.0--patch-53/type
>
>     > I'm thinking of a text file containing one of "import", "continuation" 
>     > or "simple"
>
> If you look up that name and it's not in the cache, that could result
> in a call to to `arch_revision_type'.   It could also try to avoid 
> the archive call by looking up:
>
>     address@hidden/foo--bar--1.0--patch-53/log
>
> and if that were found in the cache, inferring the type directly from
> that.

Yes, that sounds nice, though I think we need to add a distinctive
header for imports.

I'm not sure exactly what you have in mind, in terms of "cache-filling
rules".  It seems to me that having such rules makes queries act like
function calls, and if that were true, I'd think function calls were
more convenient.  Though exposing queries through the commandline
interface could be very useful to external programs.

For now, I'm thinking in terms of a dumb cache, on the assumption that
once the dumb cache is working, we can make it smart.  So my focus in on
getting things right in terms of what is stored (e.g. *not* cacherevs,
but full trees) and how things are named.

In addition to maybe_get, I'd like to see an is_cached operation, and
maybe even a list_cached operation, so we could, for example, find out
which revisions of a version had local full-tree caches.

In terms of providing estimates of answer costs, I don't think we can do
that properly until we have info on file sizes at the pfs layer.  But if
we get that, we can also expose that info, either as another operation,
or as part of the query namespace.

Aaron