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.
Hi Arthur, Arthur Barrett wrote on 29.09.2008 14:53:48: > Someone would need to manually manage the merges or one would become > authoratitive and the other not. Lots of proposed (and even dangerously > implemented) techniques for handling this are around including swful > quarum based things - but they all create more problems than they solve. agreed. > See my many previous posts about this issue: [...] Thanks for these pointers. > If you are experiencing performance problems you are far better off > describing the workflow you are using and the specific commands that > cause performance problems (and the context of those commands) and being > willing to look at traces and workflow and such things to find the > problem and fix it at the source - any multi-repository/sync 'solution' > to performance problems is generally a bandaid (however there are > occasionally sound business reasons for it, and extremely rarely sound > reasons to use it to solve performance issues). Here's what we do: 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. Project often consist of 10.000+ files, hierarchically organized, most of them text files. The simple maths is: if there would be a local mirror - the whole data would need to be transferred just once instead of once per team member - the data would usually be already available at the local mirror, so you would not have to wait for the files to update from the master server - latency to the local mirror is way lower than to the master server Cheers, Carsten