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

[Arthur Barrett]

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