[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CVS Proxy

From: loony
Subject: CVS Proxy
Date: 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 
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 
(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 
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

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 

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.


Peter Arremann.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]