Mirroring [FreeBSD WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Description =====

The %%FreeBSD%% repository is currently mirrored at over 160 different locations around the world, to provide local, read-only copies of the repository in a more network friendly fashion, and to relieve the load on the master repository.

===== Current Implementation =====

===== SVN Implementation =====

Subversion supports two mechanisms for mirroring the complete repository.

The first is to use the (new in Subversion 1.4) svnsync(1) tool.  This tool requires public read-only access to the repository to mirror (which, for any of the public mirrors is likely to be already in place -- thus, there is no requirement for a downstream mirror to communicate to an upstream mirror that it would like to start mirroring).

The target of this syncing (i.e., the mirror) can then itself be mirrored in to another repository.  This allows us to set up a chain of mirrors.

XXX - At the time of writing it is not known how svnsync(1) interacts with [[/VCSFeatureObliterate|VCSFeatureObliterate]].  More testing needs to be carried out.

An alternative approach is to use rsync.  This approach only works with Subversion repositories that use the FS (as opposed to the %%BerkeleyDB%%) backend.  If that constraint holds then the "svnadmin hotcopy" command can be run on the master repo to make a consistent snapshot of the repository.  This snapshot can then be rsynced to the mirrors.

As with svnsync, a mirror that is kept up to date in this way can also be used as the source for another mirror.

Both approaches supports pull mirroring (the remote mirror initiates the update according to its own schedule), and push mirroring (the master initiates mirroring to all the mirrors it knows about).  This would, for example, allow the master repo to push changes to all the top-tier mirrors after every single commit.

===== Hg Implementation =====

Replication is at the heart of all distributed VCS. It is as natural as
creating a new branch and uses the same mechanism. Re-creating the current
mirroring scheme is very simple, just allow remote machines to clone the
reference repositories and offer read-only http-based access.

It is more efficient than rsync as it doesn't need to scan all files for
modifications, it will simply get only the new changesets.

===== Git Implementation =====

A clone of a repository is the complete history which can easily be redeployed as a mirror. Access is usually done via git-daemon but it's also possible to deploy git over ssh and http.

===== Monotone Implementation =====
**Supported**
(also see [[http://venge.net/monotone/wiki/FeatureMirroring|monotone:FeatureMirroring]])

This feature is fundamental to [[/Monotone|Monotone]], as a distributed VCS.  There is essentially no other way of working, because every developer works with their own repository replica.

Every host is an equal peer, every user can use ''%%mtn serve%%'' in order to serve its local changes to other users via thenetsync protocol (which permits to have multiple clients connected at the same time).  Databases can also be sync'ed via ''%%file:%%'' (locally) and ''%%ssh:%%'' protocols, though this locks the database and permits only one peer at a time.

It is possible (and quite usual) to have a [[http://venge.net/monotone/wiki/MasterRepository|monotone:MasterRepository]] accessible to every developer.