CVS Proxy
lo...@loonybin.org
I'm new to the list so be a little patient if I dont make too much sense... ;)
Anyway, I'm admin for a group inside Verizon and we're using CVS for all our development.
The biggest problem we faced with CVS was that every checkout would transfer the whole tree
(around 400 MB) onto the users harddisk - and with a bandwith of as low as 160 kbit/s to
some of our remote location it would be impossible to work. This lead to creation of a
cvs extension called CVS-Proxy.
The basic functionality of CVS Proxy is pretty simple. At each remote location you have a
copy of the main repository. These repositories are kept in sync using a program called
cvssync. Right now it is a simple wrapper for rsync but I'm working on a fancier method.
When someone tries to access the repository for read, the cvs proxy checks if 'synctime'
(thats the difference between the current time and the atime of the directory the
read access is performed on) is larger than a specified parameter, a cvssync is performed
before cvs continues with its regular code.
If the access requires a write (like import or ci), CVS Proxy establishs a connection to
the master repository and all furture communication - and therefore the writes - are done
between client and master. After the transaction is finished, a cvssync is run so the local
cache contains the same data as the master.
This concept has the following advantages:
- Only one master repository so no problems with conflicts after checkin (i.e. continuus).
- Low bandwith requirements. In our furthest location (India) we sync only once a day since
the time difference makes sure that noone works at both locations at the same time.
- Since we sync after a write to the master, all behavior is identical to the original CVS,
with the exception that if you have two proxies A and B and a checkin is done in A,
it will take a max. of synctime before the code can be checked out by users of proxy B.
This has no effect on checkins!
Of course there are also disadvantages:
- Currently only pserver is implemented although other auths shouldnt be difficult either.
- with pserver (and probably others) you need to have the same logins on both the master and
the proxy.
- Space - the whole repository needs to be synced, even if you need only one of several trees
in the repository.
- Since some of the requests are handled by the proxy and others by the master, you need
to have identical cvs configurations on both systems - best is to compile from the same
source.
As stated above, we have CVS Proxy running on several systems here already and have not yet
seen any major problems and we're already talking about enhancements like a cache protocol
to reduce the amount of data that requires syncing. Also, additions to allow multiple roots
(try the cache first, if that doesnt work, go to the master) seem to be a good idea.
We're very interested in integrating our changes with the main CVS tree (currently we're based
off of 1.11) under the same license as CVS currently is. Unfortunately I couldn't find the right
person to mail about this on the cvs webpage so I decided to post here. Please contact me directly
if you're interested in my work.
Thanks,
Peter Arremann.