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

Re: Subversion presentation at Silicon Valley Linux Users Group

From: Brian Behlendorf <brian_at_collab.net>
Date: 2001-04-09 08:30:57 CEST

On 8 Apr 2001, Jim Blandy wrote:
> 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.

The issue is that someone doing an update between, say, 1.44 and 1.46
would get a delta for 2 revisions, whereas someone asking for just 1.45 to
1.46 wouldn't stand to benefit from the cached access to 1.44->1.46. If
every svn update done was done often enough that requests would always be
for delta between sequential revisions (that is, 1.45 & 1.46, etc) then
the caches would be 100% efficient. Or, when someone commits quickly
three revisions to the same resource, the svn update of everyone else
behind that cache would fetch those three revisions. I suspect that for
the most active developers (and thus those with the greatest interest in
combating latency) doing svn updates a couple times a day, the caches
should be fairly efficient.

After the 1.0 release, we could explore whether a useful optimization
would be to have the client always request sequential revisions; or
alternately, code up a plugin for the Apache proxy code that enables it to
interpret a request for 1.44->1.46 as a composition of 1.44->1.45 and
1.45->1.46, so that people who want to make their proxies more efficient
for svn can do so.

This is different than what a lot of people are talking about as
"distributed repositories", though - sometimes they mean a truely
multi-headed system where commits can be done locally and propagated to
other servers (fragile, but implemented in some tools, like Clearcase), or
the idea of "federated" servers where subservers can be set up to
implement branches with other access privs (to simplify private vendor
branches, perhaps so that later on the branch can be integrated to the
trunk with history intact.) That'll be fun to look at for 2.0.

        Brian
Received on Sat Oct 21 14:36:28 2006

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