On 3/13/07, Edward Harvey <email@example.com> wrote:
> If I can, I would like to have a svn server at location A, and another
> svn server at location B. They should both contain the same
> repositories, and all the changes should propagate everywhere.
I think you should pick the repository location, A or B, which sees
the most committed changes at any point of time. The reason is: while
replication/mirror solutions will certainly speed up updates (or any
read-only operation), commits (write operations) should propagate to
all repository servers before they are considered "complete", no
matter what solution you choose. That is the only means of preventing
one server's problem from corrupting the data of the rest, no matter
how you implement it. That means that updates (reads) can be at LAN
speed, but commits (writes) will always be at WAN speed, if you really
want to trust the data. In practice, this works out pretty well,
because read operations are far more large and frequent than write
operations, after initial repository population.
> I don't see anything written anywhere saying I can do this... But then
> again the subversion book is down right now so I haven't been able to
> look there.
Search the firstname.lastname@example.org mailing list archive. Someone
there mentioned some success at using an unstable release of SVN 1.5
on an Apache server, with the new reverse-proxy capability. HTTP read
type requests were handled on a local (LAN) repository, but write
requests were always forwarded to a central (WAN) repository. The
local repository was kept up to date using the svnsync tool, run by a
post-commit hook script on the central repository server.
You should also research SVK to see if it's right for your
environment. I personally use it as my default Working Copy client.
The author of SVK, Chia Liang Kao, also wrote a tool called "pushmi",
which allows you to set up a local repository "mirror" that
automatically forwards commit requests to the main repository. It
keeps the mirror up to date by running a command similar to "svk pull
//mirror //local" as a cron job, every 5 minutes or so. I think
"pushmi" does for svn:// access what the SVN 1.5 Apache reverse-proxy
does for http[s]:// access.
If you want less of a hack, and commercial support, look into WANdisco.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Mar 14 02:42:31 2007