[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 28 Jun 2001 22:27:49 -0400 (EDT)
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
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
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
cvssync. Right now it is a simple wrapper for rsync but I'm working on a
When someone tries to access the repository for read, the cvs proxy checks if
(thats the difference between the current time and the atime of the directory
read access is performed on) is larger than a specified parameter, a cvssync is
before cvs continues with its regular code.
If the access requires a write (like import or ci), CVS Proxy establishs a
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
- 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
- with pserver (and probably others) you need to have the same logins on
both the master and
- 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
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
to reduce the amount of data that requires syncing. Also, additions to allow
(try the cache first, if that doesnt work, go to the master) seem to be a good
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.
|[Prev in Thread]
||[Next in Thread]|