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

Re: multiple svn front-ends, single SAN repo volume

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 10 Feb 2012 23:34:56 +0100

On Fri, Feb 10, 2012 at 04:20:02PM -0600, Ryan Schmidt wrote:
> > While replicating commits, svnsync performs the exact same kinds of
> > write operations against the slave servers that happen on the master
> > repository when a client makes a commit.
> So when using svnsync one should always use a separate and preferably
> local copy of the repository(ies) on each server, yes?

Yes. That's the entire idea. Revisions are replicated by performing
a commit against the slave. The only difference to a normal commit
is that data originates from an existing revision of a different
repository, rather than a working copy.

This design allowed svnsync to reuse functionality already implemented
for normal svn clients (e.g. network support). The slave server cannot
tell the difference between an svn client and svnsync. Well, it could
by looking for revision properties of revision 0 which svnsync uses
to store meta data. But it cannot as far as the commit process is concerned.

You probably assumed that svnsync transferred underlying revision data
files across the network? That is not how svnsync operates.
But 'svnadmin hotcopy' works this way (minus the network support ;)
This is why 'svnadmin hotcopy' is faster when making a copy of a
complete repository. It performs a direct disk-to-disk copy,
and does not replay commits like svnsync does.
Received on 2012-02-10 23:35:35 CET

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

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