[cvsnt] Latest Updates - CVSNT 2.5.04 Build 3052 (RC6) and 3055(RC7)

Arthur Barrett arthur.barrett at march-hare.com
Wed May 7 11:07:50 BST 2008

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.


> 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

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

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.



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook