master TOC | chapter TOC | support
The old mirroring model had a single server as the master for all repositories. Slaves were effectively only for load-balancing reads, or for failover if the master died.
This is not good enough for corporate setups where the developers are spread fairly evenly across the world. Some repos need to be closer to some teams (NUMA is a good analogy).
A model where different repos are "mastered" in different cities is much more efficient here.
The old model had other rigidities too, though they're not really problems, as such:
the slaves are just slaves; they can't have any "local" repos.
a slave had to carry all repos; it couldn't choose to carry just a subset.
it implicitly assumed all the mirrors were under the same admin, and that the gitolite-admin repo was itself mirrored too.
In the new model, servers can be much more independent and autonomous than in the old model. (Don't miss the side note in the 'repository level setup' section if you prefer the old model).
The new model has a few pros and cons. The pros come from the flexibility and freedom that mirrors servers get, and the cons come from authorisation being more rigorously checked (for example, a slave will only accept a push if its configuration also says that the sending server is indeed the master for this repo).
A mirroring operation will not create a repo on the mirror; it has to exist before a push happens on the master. Typically, the admin on the slave must create the repo by adding the appropriate lines in his config.
If your setup is not autonomous (i.e., you're mirroring the admin repo as well) then this happens automatically for normal repos. However, wildcard repos still won't work as seamlessly as in the old model; see the first bullet in the 'IMPORTANT cautions' section earlier.
The gitolite-admin repo (and config) need not be mirrored. This allows the slave server admin to create site-local repos, without forcing him to create a second gitolite install for them.
(Site-local repos are useful for purely local projects that need not/should not be mirrored for some reason, or ad-hoc personal repos that developers create for themselves, etc.)
Servers can choose to mirror a subset of the repos from one of the bigger servers.
In the open source world, you can imagine more popular repos (or more popular parts of huge projects like KDE) having more mirrors. Or substitute "more popular" with "larger in size" if you wish (FlightGear-data anyone?)
In the corporate world it could help with jurisdiction issues if the mirror is in a different country with different laws.
I'm sure people will find other uses for this. And I'm positive the pros will outweigh the cons. If you don't like it, follow the suggestion in the side note somewhere up above, and just forget this feature exists :-)