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.
Gerhard, > It seems there was a misunderstanding. I was asking whether a > script on the > master shouldn't trigger a sync with all the slaves in case > something is > committed there, so that all slaves are updated -- rather > than a script on > the slave triggering a sync, which would only update a > specific slave when > there is a commit on its end, but not when there is a commit > to another > slave? Yes you can certainly set it up that way, but that's beyond my personal knowledge of rsync and unison. I'd usually still setup the slave to do the sync because: * two different sites using two different slaves are most likely going to be either working at different times (timezone) or on different branches or projects. * the crontab based rsync will update the other slave in due course, however if slave b does ANY commit then the rsync will update ALL changed files using my default scripts - if slave b really is idle enough for the worst case scenario (see next point) then the chances are that it wont happen anyway since being that idle noone is probably at location b. * if person a using slave a and person p using slave b both checkout hello.c 1.3, but person a commits first, then within the crontab rsync interval person b does update& commit the master will fail with hello.c 1.3 is not up-to-date. Even though the commit failed it still triggers the slave b postcommit which then does the rsync immediately. Only if this error is regularly appearing and causing loss of productivity would I consider recommending switching to a 'push' approach. Regards, Arthur Barrett