[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

caching (was: Re: Subversion presentation at SVLUG)

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-04-09 06:55:20 CEST

On Sun, Apr 08, 2001 at 12:37:15PM -0500, Jim Blandy wrote:
> Bob Miller <kbob@jogger-egg.com> writes:
> > Jim Blandy wrote:
> > > Red Hat has an office in the UK which frequently does work on a
> > > repository served from California. Certainly Subversion's improved
> > > network usage will help in some cases, but I think having a read-only
> > > cache of the repo --- perhaps one that actively watched for and
> > > downloaded commits from the master repo, to reduce first-request
> > > latency --- on their office LAN would still make a big difference to
> > > them.
> >
> > One of the points Greg (Stein) made at the SVLUG talk is that if you
> > want read-only replication, you can use a squid proxy cache.

Any caching proxy. Doesn't need to be squid. It should also allow the DeltaV
HTTP methods through.

> Well, there's a bit more work needed. To handle update requests
> helpfully, your cache needs to be able to answer requests for deltas
> between different versions, not just the texts themselves. So those
> caches are going to have to be pretty smart --- if the caches can
> produce deltas, I'd call that a distributed repository.

It will be possible to cache deltas. If the main server generates a
particular delta pair, then the cache can store that pair. It will be keyed
with the pair information and can be served up to the next person who needs
it.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:28 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.