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

[Jason McCarty]

Miles Bader wrote:
> Stig Brautaset <address@hidden> writes:
> > > > > 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.
> >
> > > The problem I'm having has to do with whether using a cached revision is
> > > the best thing for a _user_ of an archive, which varies depending on the
> > > user's environment (plus details of the source tree involved), not the
> > > server's.
> > 
> > I fail to see why --no-cache is orthogonal to your problem. If people
> > are on a slow line and need to get to your stuff often (or even
> > occasionally) they should run their own mirror. Thus you can put cached
> > revisions in _your_ mirror, but people are free to only mirror the
> > cached revisions if they want to.
> 
> It means having multiple mirrors for different users, and in fact
> multiple mirrors for different _stages_ of a user's use, and the user
> has to choose between them based on details of his environment.  Gee
> doesn't _that_ sound user-friendly!

That's not what it means. It means users would make private mirrors of
your archive and choose which revisions to cache in their own mirror.
You would publicize only your canonical mirror. This is what I do for
Tom's archive, and it's what I would recommend for users that are
interested in more than the head revisions in your archive (e.g. they
need to merge from your archive or examine old revisions with any
regularity).

For users with the opposite use-pattern, I think your idea of summary-
deltas has potential. You could choose a constant, say 4, so that you
summarize revision deltas in sets of 4. Then you would also make
summaries of the summaries (which would each span 4*4 = 16 revisions),
and so on, until you had a summary-delta which went from the first
revision almost to the last.

This would reduce bandwidth usage for users who are just grabbing
certain revisions, and probably CPU usage a little too.

The space requirements of this aren't as bad as they sound; if you chunk
your patches in sets of N, then your entire archive will be about
SIZE * N / (N - 1), where SIZE is the size of the archive without any
cached items. In other words, less than double the original size. I
think that makes summary-deltas a viable (and possibly superior)
alternative to cachedrevs.

Letting summary-deltas span branches would be another wrinkle, which I
don't feel like considering ;-)  Well, actually, I think just treating
merge points as uncrossable boundaries would work OK, if you threw in a
few bona fide cachedrevs too.

Jason