[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: background replication of repositories

From: Daniel Patterson <danpat_at_danpat.net>
Date: 2005-04-16 01:38:35 CEST

K. Richard Pixley wrote:
> I'm looking for methods of producing distributed repositories. SVK
> seems like the definitive choice, but from what I've read so far,
> appears to suffer from needing access to the "master" repository when
> doing merges into the master repository.
>
> Has anyone built a system over subversion using the clearcase multisite
> style of replication? Ie, each geographic location "owns" a branch,
> checks out from that branch, checks into that branch, and then those
> changes are transported automagically, batch style, in the background,
> to the other copies of that branch, all of which are read-only.
>
> The downside, of course, is that every site needs to merge in the
> changes from their siblings if they also want write access to that
> code. The big win is that no one has to sit around waiting for
> transactions to take place over a thin wire.
>
> Anyone done anything like this or working on anything similar?

   I setup a test repository at work once to do eactly this (we use
   Clearcase at work, this was sort of done to prove that the exhorbidant
   fees we pay for multisite were a bit unnecessary). I
   used svnmirror.sh:

     http://www.rsn.uni-rostock.de/~darix/svnmirror.sh.txt

   The only thing that you need to do is ensure that the permissions
   are managed correctly at each location so people can only write
   to the correct branches, and that the replica's know when to allow
   others to write to them. We were using mod_dav_svn so it was
   just a matter of fiddling with apache access controls.

   Note that there are a few other tools listed at the bottom of that
   page that'll do the job too.

   We even had a crack at setting up a moving-mastership style setup
   where we used ssh to change apache access controls and replication
   directions by kicking off a script (we called it
   "grant-mastership hostname", which connect to the host, found the
   current master, connected to the master, turned off mastership there
   (during this period no-one could commit anything), and turned
   on mastership at the new hostname). Worked ok in a 2 server setup.

   However, it's turned out to be much simpler just to get everyone
   to access one big central server. Our remote user count is
   very low, and while Clearcase is unusable for them without
   multisite, Subversion performance is quite acceptible.

daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Apr 16 01:41:36 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.