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.
Jan, > what's the sync protocol for? It passes writes (commit/tag) through the 'slave' to the master. > If a read-only client connected to the slave server does an > update of a file that has been changed in the master > but has not yet been rsynced to the slave, will the sync > protocol be used to provide the client with the > updates in the master, or will the client only get the > updates that had already been rsynced to the slave server? You need to ensure that the rsync is triggered by the postcommand. The crontab is a good 'backup'. In months of using it I've never seen an update NOT get the correct version. If you are particularly worried and have a very large repository you can use the postcommit as well as postcommand and in the postcommit trigger use the 'module' to qualify the rsync. This however also requires that you remove the stuff in rsync.sh that prevents two rsync's running simultaneously. Both rsync and unison are very very quick at transferring only the 'changed parts' of the 'master' RCS files down to the slave. As you can see - my 'rsync.sh' script does a 'time' on the command so I can get an idea of how long it is all taking. We did consider performing the commit at both the slave and the master - but if you have multiple slaves then this would eventually end up with something going wrong resulting in manual intervention. The way we have implemented the process nothing can go wrong that waiting an extra couple of seconds wont fix - much less administration support required! The only thing that I would have liked to have seen but we just couldn't afford the time on was somehow 'marking' files as touched/locked when we pass a write through until rsync/unison has updated them - that would have required greater interopability with rsync/unison that we had time for. I'm still not even convinced that this would really work in practice - lots to go wrong! There was a long discussion on cvsnt-dev recently about whether a single large repo or lots of small repo's are better. If you are using the master/slave feature then I can see that splitting up your repo could quicken the rsync process. Regards, Arthur