Given this, are there any plans to make svnsync capable of syncing all
metadata like revprop changes and locks? This is a critical missing
part of that tool. The subversion docs seem riddled with workarounds to
that limitation as well. It would make the system simpler, easier to
understand and easier to maintain if svnsync had the option to sync
everything.
-----Original Message-----
From: Blair Zajac [mailto:blair_at_orcaware.com]
Sent: Friday, October 23, 2009 8:40 PM
To: Anthony 'Clearly Unethical' Kilna
Cc: users_at_subversion.tigris.org
Subject: 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-backu
p
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=2411200
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-25 18:05:01 CET