SUBVERSION MIRRORING INSTALL
SUBVERSION MIRRORING CODE

If you're accessing your repository via the svn+ssh:// protocol, you've to manage the (group) permissions of the repository files in the filesystem appropriately (basically the repository should be group writable by your users). There're some things that I skipped over while writing this, mainly to do with SVN authentication. If I recall correctly I tried it but it didn't work for me, so I settled on using cron to sync up my repositories. I found this svnsync entry by Paul Querna that has a sample post-commit hook. Add a post-commit hook to the source repository.This basically runs svnsync on your destination repository server every minute to pull down any changes to your source repository. Add something like this to your crontab: * * * * * /usr/local/bin/svnsync -non-interactive sync svn://source.host/source_repos Use cron (or a similar scheduler) on the destination repository server. There are two ways you can setup 'real-time' syncing: So now you have your source and destination repositories synced, but what happens when you start committing changes to your source repository? Nothing! That's because svnsync is merely a passive syncing tool (meaning you have to run it to sync, instead of it knowing when to sync automatically). Instant gratification (well, almost)! Should your svnsync process get aborted or killed, you can remove the hanging lock by running: svn propdel svn:sync-lock -revprop -r 0 Setting up 'on-the-fly' syncing You should start seeing svnsync committing in changes from your source repository. Either way, the command to start the sync is: svnsync sync -username svnsync file:///var/svn/repositories/testsync/

SUBVERSION MIRRORING CODE

Syncing your repository data may take a long time if you have a big source repository, so I suggest using nohup to run the code overnight (or something), or at least saving the output in a log. Svnsync init file:///var/svn/repositories/destination_repos svn://source.host/source_reposĭon't worry, this only sets up the sync - there's no actual data copying yet. Make it executable, and then initialize the sync: If then exit 0 fiĮcho 'Only the svnsync user can change revprops' >&2 Create a hooks/pre-revprop-change file under your destination repository's directory. The svnsync documentation has a detailed explanation. Next, we need to create a pre-revprop-change hook for the destination repository. The svnsync program will authenticate with our repositories as this user via the svn:// protocol (i.e.

This gives read and write access to the 'svnsync user'. The easiest (and best) way to do this is edit the nf and passwd files: Setting up svnsync to mirror your repositoryįirst, create a SVN user for svnsync to use - let's call this the 'svnsync user'. With Subversion installed, create a new Subversion repository (using svnadmin create, remember?), but don't load the repository dump like we did on the main SVN server in part 1 (of course, since we are going to be mirroring the repository!).

SUBVERSION MIRRORING INSTALL

Just scp it to the mirror SVN server and install it ( dpkg -i subversion-1.4.3.deb). deb package generated by checkinstall on your main Subversion server to install Subversion 1.4.x on the mirror SVN server. This mirror SVN server also needs Subversion 1.4.x installed, so go ahead and do the (almost) same things we've done in part 1 to get Subversion installed. We've barely touched that other server that we wanted to use for mirroring the repository! 'Bootstrapping' your mirror SVN server for svnsync Phew, and that was all the work you needed to do to migrate your Subversion repository to another server. Note: if you haven't already, you may want to read part 1 of this article first.

Subversion mirroring