RE: how can I not have to spend 40 minutes _waiting_ in themorningfor each of 40 updates?

[eric.berg]

Has the suggestion to use rsync been raised here?  I'm not sure if
you're updating to different branches for the various platforms, but
exporting to one or a few locations and then running rsync to transfer
just the diffs without having to repeatedly go back to CVS might be a
workable solution.

As for time servers, you'll want to sync to several servers.  NTP's
algorithm takes travel time into account, though closer is better.

Eric 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Arthur Barrett
> Sent: Friday, October 10, 2008 4:59 AM
> To: chaitu; address@hidden
> Subject: RE: how can I not have to spend 40 minutes _waiting_ 
> in themorningfor each of 40 updates?
> 
> Chaitanya,
> 
> > CVS. But just that update takes 40 minutes. I don't really know
> > why....maybe due to the large number of files and directories? Is it
> > likely? 
> 
> No - it should be much quicker, though lots of small files do 
> mean lots
> of small queries sent to the server and so latency can become an issue
> (particularly between California and Mumbai, though the worst 
> is London
> and Sydney because the internet cables actually go London-USA-Sydney
> which is almost three quarters of the way around the globe...)
> 
> > 3. The cvs update command is not part of the build process, so the
> > "touch"ing factor is out of question. 
> 
> Perhaps you misunderstood or I was unclear.
> 
> If anything (between one update and the next days update) changes the
> date/time of the file then it causes the next and all 
> subsequent updates
> to behave really inefficiently.
> 
> 
> > Skew between local time and
> > server time.....well, I don't really know how this works across time
> > zones. 
> 
> It is all done by converting the local time to GMT/UTC.
> 
> > servers in nasa.gov. But in spite of that the boxes lose time
> > regularly....it's a nuisance I could not fix in the last 2 yrs (but
> > that's for another thread in another forum, I guess). Does it sound
> > ominous to you?
> 
> Yes - ensure that before you perform the "cvs update" you 
> sync the clock
> of both the server and the client to a common time source.
> 
> Note that you should always sync to a 'close' time source, so 
> in Sydney
> you sync to au.pool.ntp.org and in london uk.pool.ntp.org
> 
> > 4. All 40 machines are in India where I work. And the CVS 
> server is in
> > the US. Don't please ask me why it's designed that way :) . So the
> > idea of sending changed file patch across my really fast LAN would
> > sound any different now, given this geographical fact?
> 
> No - CVS was designed to be used of 75 baud phone lines - your link to
> India is much faster than that.
> 
> > 5. "when one machine is running update by itself, i.e., the other 39
> > are not updating while it is, how long does an update take? 
>  how long
> > does that update take if the sandbox is already up to date" ------
> > Almost the same. 30 minutes plus just for a silent check of the
> > sandbox and exit even if no file got updated on the server.
> 
> If you sync the server and the client to reliable time 
> sources close to
> the machine, and then run a checkout to a brand new directory how long
> does that take?  If you then resync the time and perform an update on
> the just checked out sandbox how long does that take? - I would expect
> absolutely no longer than 10 minutes for an update on a clean sandbox.
> 
> It'd also be interesting to compare those results with the same using
> compression, eg: 
>    cvs -z9 -d :pserver:california.myserver.com:/myrepo co 
> my3rdpartycode
> 
> 
> A final interesting test would be the same update but WITHOUT 
> the -d -P
> switches.  I understand what you are trying to achieve by 
> using them but
> neither should be usually required and I have seen cases where they
> cause the client to do more work than necessary.
> 
> > 6. I might say in closing that this notorious thirdparty code is not
> > even updated regularly but since one cannot predict when it is
> > updated, I have to do the cvs update daily. Is there some 
> way where I
> > can query the server to find out if any change took place so that in
> > the negative, I don't even bother to run the cvs update 
> command? Does
> > that make sense?
> 
> There are ways but most of them are tiem consuming or unreliable (the
> most common mistake is to think that the history command is
> authoritative - it's not failsafe on write so cannot be 
> guarenteed of a
> correct result).  However you can certainly write a trigger script so
> that if anything changes in the 3rd party code module that a file is
> updated - either in the cvs tree or elsewhere - then all you 
> need to do
> is check to see if that one file has changed.  This whole 
> process can be
> managed with make, something like:
> 
> Changelog.recompile: Changelog
>      cvs -z9 up -d -P 
>      touch Changelog.recompile
> 
> Ie: if every time the 3rd party code changes the file Changelog is
> updated then make will update the sandbox.
> 
> Other alternatives include:
> * switching to CVSNT 2.5.04 (linux/win/mac free etc) which 
> allows you to
> set up a 'repsoitory cache' in india to get around the latency issues
> * in India updating only the files that you KNOW have changed (see
> Todd's e-mail)
> * tar/gz the sandbox to india each day - or just a delta of 
> the changes
> (see my previous e-mail)
> 
> But I'm still convinced that you should be able to improve on the 30
> minutes for an update.  We have a not too dissimilar repository in UK
> which I use from Sydney and an update is certainly slower 
> than a closer
> server but it's still under 5 minutes even on a bad day.  The most
> likely causes are the date/time of the files being incorrect or the
> date/time of the client being incorrect.
> 
> Regards,
> 
> 
> Arthur Barrett
> 
> 
> 
> 
>  
> 
> 
> 
_______________________________________________

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
_______________________________________________