We synchronise our production repository to a backup server, using a
push model from post-commit and post-revprop hooks, and also a pull
model (from the backup server) to a different synchronised copy as an
hourly cron job.
We also make a nightly hotcopy of the repository which is backed up to
tape. The proverbial 'belt, braces, and a piece of string' backup approach.
This has run quite well for us for some years, through various 1.6.x
releases of subversion, and then 1.7.x releases.
I was recently away for a few weeks, and returned to find the pull sync
was failing, not able to lock the repository. I suspected some transient
problem, likely a network glitch, had corrupted the target. We were
running subversion 1.7.5 on both the source and target repositories.
I re-created the target repository, re-initialised the synchronisation,
and tried again. After 91 revisions copied, the svnsync command aborted.
I thought, maybe something about that revision? So I recreated the
repository, checked the permissions, and started again. After some 40000
revisions, the svnsync command aborted again.
I have since updated the target server to subversion 1.7.6, svnsync
still crashes, always at a different point.
I have just updated the source server to subversion 1.7.6, I have not
had the chance to try svnsync again, but I am not hopeful.
So, currently, we have
Production server, svnsync source repository, Ubuntu 10.04 with a hand
built subversion 1.7.6
Backup server, svnsync target repository, Ubuntu 12.04 with a hand built
subversion 1.7.6
The repository has around 77000 revisions currently.
The push svnsync still works correctly, but I am not sure if this is chance.
Unfortunately our mail gateway has a history of blocking some mails from
this list, so I will try to follow up via web archives. Replies cc'd to
me should also make it through (I hope).
Tony Butt
CEA Technologies
Canberra, Australia.
