Re: cvs up slowdown

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi James,

It does not sound to me as though posix/UTC is useful if it is different
than the TAI (Atomic Time) derived from cesium clocks.

The current difference between TAI and UTC is 33 leap seconds as of the
2006. (see http://www.ece.udel.edu/~mills/leap.html).

If posix/UTC time is only 23 seconds from UTC, then where are the other
10 seconds?

The CVS sources try to do their best to ignore the local timzeone. On
original checkout, the local file is written and its mtime is set to the
time of the original checkin of its revision using the utime() function
call.

Subsequent conversion between a time_t and a string are done by ctime()
as provided by the OS and get_time() as provided in the lib/getdate.c
file. The current time is provided to CVS using the time() function call
and some data structure use is handled via gmtime(). Times of existing
files are read using the stat() function.

On a GNU/Linux Fedora Core 3 system, I ran the following test:

 % touch f
 % perl -e '$n=time;utime $n,$n,"f"; print $n,"\n",scalar gmtime $n,"\n";'; 
TZ=right/UTC ls --full-time f;TZ=posix/UTC ls --full-time f;perl -e 'use 
File::stat; $st=stat("f"); print $st->mtime,"\n";'
 1158774625
 Wed Sep 20 17:50:25 2006
 -rw-r--r--  1 mdb sw-tools 0 2006-09-20 17:50:03.000000000 +0000 f
 -rw-r--r--  1 mdb sw-tools 0 2006-09-20 17:50:25.000000000 +0000 f
 1158774625
 %

as we can see, the mtime of the file does not change based on the
timezone. For some reason, my GNU/Linux box sees a difference of 22
seconds instead of the 23 seconds you see.

As long as CVS is doing its own stat() commands and time() and
get_date(), I suspect it should not be a problem to you.

If you do a 'cvs -ttt update ChangeLog' it will print a lot more
debugging information about what is happening.

My GNU/Linux 'man ctime' tells me that all of ctime() both gmtime()
are dealing with UTC (Coordinated Universal Time). If you could let
us know what seems to be the problem with this appraoch for you, we
would much appreciate it.

        Thanks,
        -- Mark

James Cloos <address@hidden> writes:

> >>>>> "Mark" == Mark D Baushke <address@hidden> writes:
> 
> Just to be sure everyone following this is up to speed, I should point
> out the difference between the posix and right zonefiles:
> 
> Posix has chosen to ignore leap seconds (for some definition of
> ignore; see below) and so the posix/ zonefiles -- which are also the
> default set -- do not incorporate leap seconds.  The zonefiles under
> right/, OTOH, do.  So unless you use a zonefile under right/ the
> time will be several seconds off from 'official' time.  (Currently
> posix/UTC is 23 seconds ahead of right/UTC.)
> 
> Also, you'll need a dist that installs the right/ zonefiles in order
> to play along.  Not all do -- I understand the BSDs no not -- but at
> least most of the Linux dists do.
> 
> Oh, and just to be clear, I do not use NFS.  This is all on a single
> laptop.
> 
> >> Looks like the problem stems from the use of a right/... timezone
> >> instead of a posix/... timezone.  The UTC-vs-posix difference
> >> skewed the seconds of the timestamp in Entries.
> 
> Mark> The timezone in use is UTC.
> 
> I could see from inspection that the Entries files at least attempted
> to have UTC, but the timestamps there and in the inode do not match if
> the checkout or update was run in a right/ timezone.  And the
> difference is exactly 23 seconds:
> 
> ,----
> | :; (unset TZ; /bin/ls -l --full-time ChangeLog; egrep ChangeLog CVS/Entries 
> )
> | -rw-r--r-- 1 root portage 19712 2006-05-18 15:38:27.000000000 +0000 
> ChangeLog
> | /ChangeLog/7.92/Thu May 18 15:38:04 2006//
> `----
> 
> (/etc/localtime is linked to UTC, which is the same as posix/UTC.)
> 
> Compare that with:
> 
> ,----
> | :; (env TZ=right/UTC /bin/ls -l --full-time ChangeLog; egrep ChangeLog 
> CVS/Entries )
> | -rw-r--r-- 1 root portage 19712 2006-05-18 15:38:04.000000000 +0000 
> ChangeLog
> | /ChangeLog/7.92/Thu May 18 15:38:04 2006//
> `----
> 
> So, either the timestamp in the Entries file is wrong, or the timestamp
> provided to the_logical_equivalent_of_touch(1) is wrong, or there is a
> bug in glibc that shows up when using a right/ zonefile.
> 
> I presume the timestamp is sent in text over the pserver protocol,
> yes?  And that is used as-is in the Entries file?  How is that then
> converted to seconds-since-the-epoch for the purpose of setting the
> timestamp in the inode?  Either that, or the libc function called to
> set the inode's timestamp would seem to be the weak point.
> 
> -JimC
> -- 
> James Cloos <address@hidden>         OpenPGP: 0xED7DAEA6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFFEYGaCg7APGsDnFERAn63AJ9/Yyfjf1Uyj51JdrPXAuTYZ36a7wCdGj97
y+YZ6ahPH9z8wscFxdCcG9I=
=E6wY
-----END PGP SIGNATURE-----