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, > > No - it is as Jan already replied. The slave passes all > the writes to > > the master which would then fail the commit. The system is > failsafe in > > this way. > > Now that I read it a second time, I got it :-) > > So this is not two local cvsnt servers, that synchronize once > in a while, 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. > but it is more of one cvsnt server and one cvs-proxy-with-local-cache. Something I should have pointed out in my previous post is that the whole replication/sync thing is completely unnecessary. This question of 'sync' is usually asked by people who are not using CVS well and therefore experiencing performance issues. CVS was designed over 20 years ago for use on networks that ran at a fraction of the speed of todays slowest networks - you never ever ever need more than one repository server to solve performance issues even on the slowest network. See my many previous posts about this issue: http://groups.google.com/group/gnu.cvs.help/browse_thread/thread/ec4fba7 9f74f1d6c/b45714caacdfc8ea?lnk=gst&q=RE%3A+Performance+of+CVS+version+SV N#b45714caacdfc8ea And http://groups.google.com/group/gnu.cvs.help/browse_thread/thread/a542321 3e11193c2/134ef39166ec266b?lnk=gst&q=Repository+synchronization+between+ two+cvs+server#134ef39166ec266b And http://groups.google.com/group/gnu.cvs.help/browse_thread/thread/43807d8 6f66f1b7d/e2b28c52154b583d?lnk=gst&q=Repository+synchronization+between+ two+cvs+server#e2b28c52154b583d And many many more... (Note your e-mail reader may 'split' those links over multiple lines, so you may need to paste them together before using them). 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). Regards, Arthur Barrett