[Gnu-arch-users] Arch caches

[Aaron Bentley]

This is mostly supplemental to my last email.  I've been doing some more 
thinking about this, because caching archives solves several problems we 
get with mirrors.

- You can still commit
- You don't download anything you don't need
- limit-based mirroring causes you to get false data about what 
categories, branches, etc are available on the mirror

> > It is clearer to view what you are calling "transient information" as
> > permanent data for which only imperfect access methods exist.

Here's my latest thinking:
Given sufficient history, the source tree for a revision is well 
defined.  However, the presence or absense of cacherevs isn't data about 
 the archive at all.  It's data about a given archive location. 
Archive data is immutable.  Archive location data is transient.


> >   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"


address@hidden/foo--bar--1.0--patch-53/ancestor

I figure we can generalize CONTINUATION as ancestor, and use it for both 
simple and continuation revisions.  Sort of like using full-tree.tar.gz 
to represent both imports and cacherevs

address@hidden/foo--bar--1.0--patch-53/log

The patchlog for the revision.


address@hidden/foo--bar--1.0--patch-53/changeset.tar.gz

This would be one option for naming the cacherev.  I don't like it, 
though.  Because it would make sense to cache deltas as well.  And then 
you'd wind up with redundant data in the cache.


address@hidden/foo--bar--1.0--patch-53/delta-from-foo--bar--1.0--patch-52.tar.gz

This would be more general, so it would support commit changesets, but 
also changesets produced by tla delta.  And with an ancestor file for 
all changeset-based revisions, it would be dead simple to produce.

If you really wanted to differentiate commit changesets from the rest, 
we could use some kind of symlink:

address@hidden/foo--bar--1.0--patch-53/delta-from-foo--bar--1.0--patch-52.tar.gz 
-> address@hidden/foo--bar--1.0--patch-53/changeset.tar.gz


address@hidden/foo--bar--1.0--patch-53/delta-from-foo--bar--1.0--patch/mod-files-index

This would be one approach, but it does tie us to a particular changeset 
format.

You've also mentioned storing revision meta-info in a separate file from 
the log, and I like that idea.

> > We can extend a general
> > purpose cache archive-side.    I suppose the most important thing I'm
> > recommending is the get/put style interface using an extended arch
> > namespace.    Parts of the cache could conceivably (or reconceivably
> > already do) reside archive-side.

Hmm.  By definition, an Arch cache should support all archive data.  It 
would be possible for archive-side caches to actually *be* the archives.

Aaron