Repository replication and caching may be configured so that remote locations can have fast access for read operations while keeping changes stored in a master repository. If the master repositoryy goes offline then people at the remote location can continue to work or one of the remote caches can be re-configured to be the new master.
The fisrt thing to consider is whether replication and caching are needed at all. CVS was designed for networks that were much slower and less reliable that are available today, so even without replication and caching it should perform adequately for large remote teams using a central repository located in the same or a distant continent. If you are considering repository replication and caching primarily to improve performance then you should instead address the causes of the performance issues first by contacting the CVSNT Newsgroup or purchasing commercial support from the project sponsor (Appendix G, Dealing with bugs or getting help).
After much analysis and discussion internally the CVSNT developers could not see any benefit for repository replication and caching since the CVSNT protocol was designed for telecommunications networks far slower and less reliable that what is commonly available today.
Secondly in hypotheticals about 'if we did do multi-repos' - we could not see any benefit in a quorum based system where the changes on one repository are mulitcast to several servers simultaneously, since the quorum needs to be tracked and the 'excluded members' of the quorum are just as incapable of accepting patches as is a single repository shadow.
The solution we have come up with is a 'master' repository and multiple shadows. If you like you can change which is the 'master' at any time you like.
The CVSNT developers have been using the 2.5.04 repostiory cache feature since 2007 internally between Manchester UK and Sydney Australia and it works very well - and if you have large binaries in the repository or your processes require 'fresh checkouts' rather than 'updates' then installng a shadow does improve performance.
Changing your procedures to use 'udpate' would do the same thing and requires much less effort than setting up repository replication.
It cannot be stressed enough just how unnecessary repository replication and caching is for 99.9% of organisations as teams - if you are experiencing multi site performance problems there are probably much 'better' ways to fix it that using repository replication and caching.
If you want more info on repository replication please see the previous newsgroup posts:
1.
http://www.cvsnt.org/pipermail/cvsnt/2008-May/030637.html
And
1.
http://www.cvsnt.org/pipermail/cvsnt/2008-May/030642.html
And
1.
http://www.cvsnt.org/pipermail/cvsnt/2008-May/030653.html
And
1.
http://www.cvsnt.org/pipermail/cvsnt/2008-May/030655.html
And
1.
http://www.cvsnt.org/pipermail/cvsnt/2008-May/030659.html
.
CVSNT provides the following specific repository replication an caching features:
It is also necessary to configure the synchronise to occur at intervals when the caching server is inactive (the quality assured CVS Suite includes a SYNC scheduler)
The SYNC protocol to 'pass through' changes form a local cache to the master server, and
The UNISON port on the Master server to allow caching clients to obtain delta copies of the repository (Unison is included in the quality assured CVS Suite only)
Triggers to automatically activate synchronising changes from the master server back to the local cache (the quality assured CVS Suite includes a SYNC trigger)