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

Re: Case study: Mono switches to Subversion

From: Jani Averbach <jaa_at_jaa.iki.fi>
Date: 2004-11-18 08:27:57 CET

Automatic master / slave servers

The idea is that we have two repository urls in the working copy,
an url for read-only operations, and an url for writable operations.

At the first phase setting these urls up could be a manual operation:

   svn co http://svn.collab.net/repos/svn/trunk
   svn slave http://my.local.slave/repos/svn/trunk

And in second phase they could be propagated automatically from
server when you do an initial checkout.

After these urls have been set up, all read only operations happens
against your local mirror (there might be a switch to force to use
master), and all operations which write to the repository happens
againts master, automatically.

So, with this scheme, huge amount of load and net traffic disappears
from server, all 'svn log', 'svn diff -rX:Y', 'svn blame', 'svn up'
etc. happen from the slave. In the extreme case, you could run your
very own mirror on your own machine or laptop, and to be able to run
all operations offline, expect those which will change something in
the repository. And all this with standard svn client.

We already have means to sync servers, and with FSFS it could be
possible to use even rsync for syncing. So this part isn't a problem.

The client could use the existence of "ro-url=...." entry in the
entries file as an indicator if this is master-slave or only master

With this kind of system, we could at least help some of the problems with
Mono and other large scale projects:

- Server load & network traffic
    (svn blame, svn log, svn diff -rX:Y, svn up)

- Have more offline operations
    (svn blame, svn log, svn diff -rX:Y)

- You are not so dependent of the server, if it is out of order, the
  effects are not so severe.

With big, geographically sparce projects the benefits could be very
real. What do you think?

BR, Jani

Jani Averbach
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 18 08:28:17 2004

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.