[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Miles Bader
Subject: [Gnu-arch-users] situations where cached revisions are not so good
Date: 24 Sep 2003 14:31:32 +0900

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


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?

reply via email to

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