Re: vc-cvs-parse-entry

[Eli Zaretskii <eliz@gnu.org>]

> Cc: rudalics@gmx.at,  emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 30 Aug 2006 17:01:38 -0400
> 
> >> >> What system is that (w32?)?
> >> > In GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000)
> >> Then it's a known problem that's pretty hard to fix:
> >> w32 handles DST by changing the definition of "time 0"
> > This is not really accurate, at least on newer versions of Windows;
> > see below.
> 
> It may have been fixed since w98, but I'm pretty sure that's how w98 did it.

The NTFS filesystem stores file times in UTC, but other file systems
don't, even when the OS is Windows XP.  See:

  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/file_times.asp

> >> IIRC "cvs update" will fix things for you.
> 
> > Yes, but it's _awfully_ slow.  I needed to write a program to move the
> > files' last write timestamp by N hours, to avoid the resultant lossage
> > on Windows, whereby "cvs up" after a DST change can take _hours_
> > because each file is sent upstream due to the time mismatch.
> 
> The "time mismatch" you see is in CVS, not in Emacs.  vc-cvs.el suffers from
> the same time mismatch because it uses the same algorithm (except it's
> written in elisp instead of C).

Given that Emacs running on NTFS will (or at least could) see true UTC
file times, I don't see why it should see any mismatch whatsoever.
Perhaps someone who has a working vc-cvs setup on NTFS could see if
this problem still exists there.

> I don't think vc-cvs.el should try to be more clever than CVS
> itself.

I don't see why we should replicate problems with ported CVS clients.

> Note that if more recent versions of w32 fixed this problem, it should be
> fixed for both CVS and vc-cvs.el (and pcl-cvs ;-).

Only if the CVS client uses the right code to get the file times; see
the above URL for the gory details.