[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Arch caches
From: |
Aaron Bentley |
Subject: |
[Gnu-arch-users] Arch caches |
Date: |
Sat, 04 Sep 2004 12:08:30 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (X11/20040306) |
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
- [Gnu-arch-users] Arch caches,
Aaron Bentley <=