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

Re: caching proxies and SVN network perf

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-10-24 12:30:20 CEST

On Mon, Oct 23, 2000 at 06:02:49PM -0500, Jim Blandy wrote:
> > Let's consider the case where SourceForge uses SVN for the projects. SF is
> > located in California. Now, let's turn to the European developers trying to
> > get stuff out of SF. What should they do? Point their SVN client at a
> > caching proxy located in Europe. John checks out some GNOME project, which
> > loads it into the cache. (note: versions are immutable, so the cache will
> > hold onto that particular version until the cache's FIFO strategy tosses the
> > file out; it won't ever expire) Now, Jane comes along and checks out the
> > same project. Hey! She gets it directly from the cache. No cross-atlantic
> > checkout. Of course, caching proxies at business network edges also provide
> > the same benefits.
> Will existing implementations HTTP proxies correctly cache SVN
> traffic? It's going to take some thinking for me to comprehend that.

Absolutely. A "checkout" is simply a series of HTTP GET operations. The
cache is *definitely* going to hold onto those.

It could probably do diffs, but I'll have to get some stuff implemented
because I'm not exactly sure how we'll be implementing the diff draft
(referenced from the webdav-design.html document in CVS). Specifically, that
should have some "Vary:" headers which would help control how the proxies
will cache and under what "key", if you will.

But the bulk: big time.

Just think... an SVN repository getting picked up and shared across the
akamai caching network! Woo!



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

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