Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Carsten, > The CVS server is located at location A, where some > team members work. CVS is fast for those guys. > > Some other guys work at location B and have to > connect to the CVS server at location A. CVS > updates are slow for them. What update command are they using - exactly what parameters? When are they running the command (how often)? What protocol are they using? Do you have protocol compression on? When they run the update - is anything fetched? If you enable server side tracing and use "cvs -ttt up" on the client can you see any points where there is an obvious slowdown? No matter how slow the connection - "cvs up" generally will be very fast. Common technical causes of the problem you are seeing include: not compressing the protocol, not disabling 'reverse dns lookups' on the cvsnt server, not syncing the time between clients and server. Common workflow causes of the problem you are seeing include: using "cvs up" when unnecessary, using 'cvs co" when unnecessary. > Project often consist of 10.000+ files, hierarchically > organized, most of them text files. Not unusual and shouldn't cause any problems. > The simple maths is: if there would be a local mirror Yes - it's an easy solution and having a local mirror allows your developers to work with poor workflow. We added the sync protocol since you are not alone in seeing this as the only way to solve these problems. By all means go ahead and use it, it will deliver all the improvements you list. It doesn't mean that there are not far easier ways to solve the problem without it. Regards, Arthur