Hi,
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.
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
