From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: vc-cvs-parse-entry Date: Sat, 02 Sep 2006 15:32:23 +0300 Message-ID: References: <44F4A8D0.6090304@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1157200368 31413 80.91.229.2 (2 Sep 2006 12:32:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 2 Sep 2006 12:32:48 +0000 (UTC) Cc: rudalics@gmx.at, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 02 14:32:48 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GJUg1-0006pZ-On for ged-emacs-devel@m.gmane.org; Sat, 02 Sep 2006 14:32:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJUg1-0002oK-7T for ged-emacs-devel@m.gmane.org; Sat, 02 Sep 2006 08:32:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GJUfk-0002l6-06 for emacs-devel@gnu.org; Sat, 02 Sep 2006 08:32:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GJUfh-0002gZ-Kp for emacs-devel@gnu.org; Sat, 02 Sep 2006 08:32:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJUfh-0002gD-F6 for emacs-devel@gnu.org; Sat, 02 Sep 2006 08:32:25 -0400 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GJUpl-0000Ib-Jc for emacs-devel@gnu.org; Sat, 02 Sep 2006 08:42:49 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-70-232.inter.net.il [80.230.70.232]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id ENX75199 (AUTH halo1); Sat, 2 Sep 2006 15:32:23 +0300 (IDT) Original-To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Wed, 30 Aug 2006 17:01:38 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:59251 Archived-At: > Cc: rudalics@gmx.at, emacs-devel@gnu.org > From: Stefan Monnier > 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.