[Top][All Lists]

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

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

From: Miles Bader
Subject: [Gnu-arch-users] Re: situations where cached revisions are not so good
Date: 24 Sep 2003 18:41:22 +0900

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:




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.

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

reply via email to

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