Svn Problem Overview
My company has a subsidiary with a slow Internet connection. Our developers there suffer to interact with our central Subversion server. Is it possible to configure a slave/mirror for them? They would interact locally with the server and all the commits would be automatically synchronized to the master server.
This should work as transparently as possible for the developers. Usability is a must.
Please, no suggestions to change our version control system.
Solution 1 - Svn
It is possible but not necessarily simple: the problem you are trying to solve is dangerously close to setting up a distributed development environment which is not exactly what SVN is designed for.
The SVN-mirror way
You can use
svn mirror as explained in the SVN book documentation to create a read-only mirror of your master repository. Your developers each interact with the mirror closest to them. However users of the slave repository will have to use
svn switch --relocate master_url
before they can commit and they will have to remember to relocate back on the slave once they are done. This could be automated using a wrapper script around the repository modifying commands on SVN if you use the command line client. Keep in mind that the relocate operation while fast adds a bit of overhead. (And be careful to duplicate the repository uuid - see the SVN documentation.)
[Edit - Checking the TortoiseSVN documentation it seems that you can have TortoiseSVN execute hook scripts client side. You may be able to create a pre/post commit script at this point. Either that or try to see if you can use the TortoiseSVN automation interface to do it].
The SVK way
svk is a set of Perl scripts which emulate a distributed mirroring service over SVN. You can set it up so that the local branch (the mirror) is shared by multiple developers. Then basic usage for the developers will be completely transparent. You will have to use the svk client for cherry picking, merging and starmerging. It is doable if you can get your head around the distributed concepts.
The git-svn way
While I never used that myself, you could also have distant developers use git locally and use the git-svn gateway for synchronization.
It all depends on your development environment and the level of integration you require. Depending on your IDE (and if you can change SCM) you might want to have a look at other fully distributed SCMs (think Mercurial/Bazaar/Git/...) which support distributed development out of the box.
Solution 2 - Svn
Subversion 1.5 introduced proxy support when you're using http to host your repository. Developers can checkout their working copies from the slave. Then all read-only operations (diff, log, update etc) will use the slave. When committing, the slave transparently passes all write operation to the master.
Solution 3 - Svn
You should try The SVK version control system
> SVK is a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools.
On this link there is text about Using SVK to Synchronize SVN Repositories
Solution 4 - Svn
If one of the repositories is fully read only you can use 'svnsync' to keep it up to date with the master repository. This tool is often used in combination with the proxy support to create a master slave setup.
E.g. Apache does this to mirror their repository to different continents. The master repostitory is located in the US, but if I access the repository from the EU I get a local mirror that works just as well as the master server.
Solution 5 - Svn
The inotify-tools works well for me, details are mentioned on this website:
Solution 6 - Svn
There is a commercial solution that provides true active-active replication (not master-slave) of Subversion repositories if you need performance and data safety beyond what svnsync provides called "Subversion MultiSite".
Disclaimer: I work for the company that makes this solution
Solution 7 - Svn
VisualSVN Server's Multisite Repository Replication was designed for this case.
You can keep the master repository in your main office and setup multiple writeable slave repositories at the remote locations.
> This should work as transparently as possible for the developers. > Usability is a must.
The replication between the slaves and the master is transparent and automatic,
Each master and slave repository is a writable Subversion repository from the user's standpoint,
Works out-of-the-box and can be configured in a couple of clicks via VisualSVN Server Manager MMC console.