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

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

http://svn.collab.net/repos/svn/trunk/contrib/server-side/svn-fast-backup

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.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair_at_orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2410823
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].