Justin Erenkrantz <jerenkrantz@apache.org> writes:
> A slave repository has a local copy of the repository and will respond
> to all read operations. For any write operations, it will
> transparently pass through the write operations to the master. On
> completion of the commit, the master server will update the slaves via
> a post-commit hook (currently using svnadmin incremental dumps).
Wow, this is almost exactly what we wrote in our "blue sky" feature
list, in the design document, over two and half years ago. Sorry I
didn't say so before, Justin, but this sounds really neat. I'd also
like to see this developed on a branch, provided it was carefully
documented.
Here's the original excerpt --
(From http://svn.collab.net/repos/svn/!svn/bc/1/trunk/\
doc/programmer/design/future.texi:)
@node Mirroring Servers
@subsection Mirroring Servers
This is like the ClearCase multisite feature. Essentially, it is a
redundant distributed repository. The repository exists on two or
more cooperatively mirroring servers (each one presumably being close,
network-wise, to its intended users). A commit from any user is visible
on all the servers.
The best way to implement this is by creating a ``hierarchy'' of
Subversion servers, much like the DNS or NIS system. We can define a
server @dfn{master} to contain the ``authoritative'' repository. We can
then set up any number of @dfn{slave} servers to mirror the master. The
slave servers exist primarily as local caches; it makes @code{reads} and
@code{updates} faster for geographically disperse users. When a user
wishes to @code{commit}, however, her delta is always sent to the master
server. After the master accepts the change, the delta is automatically
``pushed'' out to the caching slave servers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 13 17:20:17 2002