[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.


Say we used the above to represent cacherevs and imports.  We'd also want


I'm thinking of a text file containing one of "import", "continuation" or "simple"


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


The patchlog for the revision.


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.


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


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.


reply via email to

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