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

[Miles Bader]

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!

I.e., instead of just address@hidden', I'll need:

  address@hidden

  address@hidden

  address@hidden

The user shouldn't be making decisions like this, the implementation
should be.  I think any time you need a _discussion_ of which mirror is
the best one to use, something's wrong (which is why I'm going to put
.listing in all of my mirrors, BTW).

Morever, the solution of `just don't use cached revisions' is pretty
lame, because it _does_ get annoying to have star-merge replay 150
changesets (twice!).  I think my idea of `cached changeset summaries'
seems reasonable for this.

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein