1

We have several sites and are using one centralized subversion repository.

The repository is large and network bandwidth means it takes several hours to get sources between sites.

What you would advise? One option is to start using Git but it could be very expensive. What about still having one central SVN repository at the main site and have git installed at the small sites and then we can use git-svn conduit?

James Reed
  • 13,873
  • 51
  • 60
yart
  • 7,515
  • 12
  • 37
  • 37
  • 1
    Why would using git be expensive? – James Reed Feb 19 '13 at 10:27
  • 1
    @James Reed, I mean switching to it would be or better to say could be expensive. – yart Feb 19 '13 at 10:40
  • 1
    What do you mean by "it takes several hours to get sources between sites"? Which subversion commands are slow? – AlexMA Feb 19 '13 at 13:41
  • @AlexMa, svn update as example but the reason could be that the number of sources is too big and connection required to remote server. – yart Feb 19 '13 at 21:55
  • @yart Hmm... well if svn update is slow, then either your network connections is *really* slow or your working copy is very different from the HEAD revision. SVN only passes the differences over the network. Are you versioning large binary files? – AlexMA Feb 19 '13 at 22:30

3 Answers3

2

  1. Make sure you're using 1.7+ version of Subversion server and client. Version 1.7 had introduced certain performance improvements, especially for http(s):// protocol.

  2. git-svn uses standard SVN protocols, so it's not going to fix the speed of communicating with Subversion server.

    However, since most of Git operations are local, users have to interact with the server more rarely. Basically, there are only two slow commands in this case: git svn dcommit and git svn fetch.

  3. Consider using SubGit for your SVN repository. SubGit performs server-side synchronization between SVN and Git repositories, both SVN and Git sides remain writable.

    Once you've installed SubGit and setup Git server you can use pure Git in order to pull and push changes; on every git push SubGit translates commits to SVN revisions and on every svn commit it translates committed revision to Git commit.

    Note that in this case you're using Git protocol which may result in significant speed improvements.

    For more details on SubGit please refer to documentation and comparison with git-svn.

    Disclaimer: SubGit is a commercial software; I'm one of SubGit developers.

vadishev
  • 2,979
  • 20
  • 28
0

You can try Multisite Repository Replication with VisualSVN Server.

Multisite Repository Replication allows you to setup a master repository on your main site with multiple slave repositories installed at other remote locations. Bidirectional data replication between slaves and a master is transparent and automatic, each slave and a master are writeable and act as a regular Subversion repository from the client point of view.

bahrep
  • 29,961
  • 12
  • 103
  • 150
-1

If you want to stick with a purely Subversion toolchain, look into doing the following:

What you'll end up with is one master repository at the central location, and a read-only mirror copy at each of your sites. Users at those sites will check out from their local mirror.

You then configure those mirrors with write-through proxying, which will push the commits back to the master repository.

After each commit, the repository then uses svnsync to push that revision out to the mirrors.

If that's still too slow, you may need to look into WanDisco SVN MultiSite.

alroc
  • 27,574
  • 6
  • 51
  • 97