[Gnu-arch-users] situations where cached revisions are not so good

[Miles Bader]

Someone recently asked me to add a cached revision for my emacs archive,
which according to the conventional wisdom would make sense, since
there's quite a few changesets in there.

But I now realize that it's actually maybe not the right thing, because
the emacs sources are very big relation to the size of changesets.  For
someone doing a completely raw `tla get', the cached revision will help,
but for anyone else, it's probably worse than just fetching all the
changesets.  However it _also_ depends on your network connection --
someone with a very fast pipe may prefer to transfer the additional data
to save a bit of cpu time somewhere.

Anyway, I'm wondering if anyone can think of a good solution to this;
cached revisions are nice in general, but it would be good to have
someway of mediating their use, such as `use this cached revision only
if you have no other version installed (e.g., a `tla get' with no
revision library or pristine trees available)'.

A possible _alternative_ to the current notion of cached revisions that
might work better in cases like emacs might be a `cached summary delta',
which merely collapses a ranged of changesets into a single big
changeset; like a normal cached revision, this is something that would
be stored in addition to a normal changeset, and only used optionally.
cacherev could try to be clever and create one or the other depending
on relevant variables, such as the total source-tree size, and the size
of the `summary delta.'

Ideas?

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?