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

Re: Rsync versus svnsync + hook scripts for revprop and lock syncing

From: Blair Zajac <blair_at_orcaware.com>
Date: Fri, 23 Oct 2009 20:39:53 -0700

On Oct 23, 2009, at 5:32 PM, Anthony 'Clearly Unethical' Kilna wrote:

> I have a subversion 1.6 server with many repositories mirrored to a
> read-only secondary (it’s hot standby)… we’re currently propagating
> commits via a screen session with svnsync’s in while loops
> continuously updating running on the secondary. It seems sub-optimal.
> We are also propagating revprop changes via a post-revprop-change
> script which writes data back into a special place in svn and a cron
> process on the secondary which will set the revprop triggered by the
> commit on the master.
> We’re now looking at implementing write-through proxying so we can
> use a secondary for better performance at a remote location. This
> means yet another sync process or post commit hook which will
> propagate any locks changes from the primary to the secondary.
> To me at this point, I feel like rather than deploy and test yet
> another sync process which could potentially break (since it’s
> likely we’ll be spicing it with our own customizations for
> robustness), wouldn’t it make sense to drop the 3 separate processes
> for propagating different kinds of changes to the secondary, and
> simply switch to rsync with some special syntax to prevent the hooks
> directory from being synchronized?
> What would be the disadvantages of going this route? Has anyone
> used this method? Am I correct in my assumption that if the files
> on the filesystem are kept in sync with the exception of the hook
> scripts and svn configs which need to be different for masters/
> slaves, that nothing else needs to change?

You need to ensure that rsync orders the files to sync in the same
order as svn writes them otherwise you can end up with a broken
repository. If rsync is syncing while there's a transfer then the
current file in the fsfs repository could refer to revisions that
don't exist in the revs and revprops directory. See


But after a certain size it'll take more time for rsync to scan the
entire repository than it will for svnsync to sync the new commits over.


Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
Subversion training, consulting and support
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-24 05:41:06 CEST

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