[ACCEPTED]-How to synchronize two Subversion repositories?-synchronization

It is possible but not necessarily simple: the 41 problem you are trying to solve is dangerously 40 close to setting up a distributed development 39 environment which is not exactly what SVN 38 is designed for.

The SVN-mirror way

You can use svn mirror as explained 37 in the SVN book documentation to create 36 a read-only mirror of your master repository. Your 35 developers each interact with the mirror 34 closest to them. However users of the slave 33 repository will have to use

svn switch --relocate 32 master_url

before they can commit and they 31 will have to remember to relocate back on 30 the slave once they are done. This could 29 be automated using a wrapper script around 28 the repository modifying commands on SVN 27 if you use the command line client. Keep 26 in mind that the relocate operation while 25 fast adds a bit of overhead. (And be careful 24 to duplicate the repository uuid - see the SVN documentation.)

[Edit 23 - Checking the TortoiseSVN documentation it seems that 22 you can have TortoiseSVN execute hook scripts client side. You may be able 21 to create a pre/post commit script at this 20 point. Either that or try to see if you 19 can use the TortoiseSVN automation interface to do it].

The SVK way

svk is a set of Perl 18 scripts which emulate a distributed mirroring 17 service over SVN. You can set it up so that 16 the local branch (the mirror) is shared 15 by multiple developers. Then basic usage 14 for the developers will be completely transparent. You 13 will have to use the svk client for cherry 12 picking, merging and starmerging. It is 11 doable if you can get your head around the 10 distributed concepts.

The git-svn way

While I never used 9 that myself, you could also have distant 8 developers use git locally and use the git-svn gateway 7 for synchronization.

Final words

It all depends on your 6 development environment and the level of 5 integration you require. Depending on your 4 IDE (and if you can change SCM) you might want 3 to have a look at other fully distributed 2 SCMs (think Mercurial/Bazaar/Git/...) which support distributed 1 development out of the box.

Subversion 1.5 introduced proxy support 6 when you're using http to host your repository. Developers 5 can checkout their working copies from the 4 slave. Then all read-only operations (diff, log, update 3 etc) will use the slave. When committing, the 2 slave transparently passes all write operation 1 to the master.

You should try The SVK version control system

SVK is a decentralized version 6 control system built with the robust Subversion 5 filesystem. It supports repository mirroring, disconnected 4 operation, history-sensitive merging, and 3 integrates with other version control systems, as 2 well as popular visual merge tools.

On this 1 link there is text about Using SVK to Synchronize SVN Repositories

If one of the repositories is fully read 9 only you can use 'svnsync' to keep it up 8 to date with the master repository. This 7 tool is often used in combination with the 6 proxy support to create a master slave setup.

E.g. Apache 5 does this to mirror their repository to 4 different continents. The master repostitory 3 is located in the US, but if I access the 2 repository from the EU I get a local mirror 1 that works just as well as the master server.

The inotify-tools works well for me, details 1 are mentioned on this website:

http://planet.admon.org/synchronize-subversion-repositories-with-inotify-tools/

There is a commercial solution that provides 5 true active-active replication (not master-slave) of 4 Subversion repositories if you need performance 3 and data safety beyond what svnsync provides 2 called "Subversion MultiSite".

Disclaimer: I 1 work for the company that makes this solution

VisualSVN Server's Multisite Repository Replication was designed for this 12 case.

You can keep the master repository 11 in your main office and setup multiple writeable 10 slave repositories at the remote locations.

This 9 should work as transparently as possible 8 for the developers. Usability is a must.

• The 7 replication between the slaves and the master 6 is transparent and automatic,

• Each master 5 and slave repository is a writable Subversion 4 repository from the user's standpoint,

• Works 3 out-of-the-box and can be configured in 2 a couple of clicks via VisualSVN Server 1 Manager MMC console.