Re: Why does cvs wait to the next second?

[Paul Sander]

The reason for the sleep is so that timestamps in the sandbox can stabilize 
before subsequent actions.  It puts some separation between the stamps on 
checked-out sources and subsequent modifications and additions by other aspects 
of the users' process.  Removing the sleep will cause non-deterministic 
failures and you'll find that you'll have to re-introduce it in some of your 
scripts that invoke cvs.

The specific reason for this is because CVS assumes that it was the last to 
modify a file if its mod time matches the one recorded in its Entries file.  If 
it's quickly modified by something else, then CVS may still think it's up to 
date and both "cvs update" and "cvs commit" will produce incorrect results.

There has been much discussion on this topic, and you can see discussion of the 
rationale in the info-cvs archives.

On Dec 25, 2012, at 11:57 AM, Urs Thuermann wrote:

> I have observed that the same CVS checkout command takes different
> running times on multiple calls and that a script calling cvs checkout
> many times takes very long.  Using strace I see that CVS waits for the
> next second start after its work has been done, right before exiting:
> 
> Trace of first call to cvs checkout <dir>
>    ...
>    20:50:17.149775 close(4)                = 0
>    20:50:17.149807 time([1356465017])      = 1356465017
>    20:50:17.149840 time([1356465017])      = 1356465017
>    20:50:17.149873 nanosleep({0, 850134000}, NULL) = 0
>    20:50:18.000114 time([1356465017])      = 1356465017
>    20:50:18.000154 nanosleep({0, 20000000}, NULL) = 0
>    20:50:18.020252 fchdir(3)               = 0
>    20:50:18.020289 close(3)                = 0
>    20:50:18.020328 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
>    20:50:18.020372 close(1)                = 0
>    20:50:18.020406 munmap(0x7f9d28936000, 4096) = 0
>    20:50:18.020487 exit_group(0)           = ?
> 
> Another call to cvs checkout <dir>
>    ...
>    20:50:31.325934 close(4)                = 0
>    20:50:31.325968 time([1356465031])      = 1356465031
>    20:50:31.325991 time([1356465031])      = 1356465031
>    20:50:31.326013 nanosleep({0, 673991000}, NULL) = 0
>    20:50:32.000130 time([1356465031])      = 1356465031
>    20:50:32.000186 nanosleep({0, 20000000}, NULL) = 0
>    20:50:32.020282 fchdir(3)               = 0
>    20:50:32.020320 close(3)                = 0
>    20:50:32.020364 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
>    20:50:32.020413 close(1)                = 0
>    20:50:32.020448 munmap(0x7f905e4fb000, 4096) = 0
>    20:50:32.020564 exit_group(0)           = ?
> 
> And a third call to checkout that smae directory.
>    ...
>    20:50:45.906568 close(4)                = 0
>    20:50:45.906601 time([1356465045])      = 1356465045
>    20:50:45.906633 time([1356465045])      = 1356465045
>    20:50:45.906667 nanosleep({0, 93340000}, NULL) = 0
>    20:50:46.000104 time([1356465045])      = 1356465045
>    20:50:46.000144 nanosleep({0, 20000000}, NULL) = 0
>    20:50:46.020238 fchdir(3)               = 0
>    20:50:46.020274 close(3)                = 0
>    20:50:46.020313 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
>    20:50:46.020357 close(1)                = 0
>    20:50:46.020391 munmap(0x7f2c8f6a2000, 4096) = 0
>    20:50:46.020469 exit_group(0)           = ?
> 
> What is the reason for CVS to do this?  Is it because of time stamps
> for history entries?  And can I prevent CVS from sleeping?
> 
> urs
>