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?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2410801
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-24 03:56:51 CEST