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 16:10:57 +0300 Message-ID: References: <44F4A8D0.6090304@gmx.at> <44F5D00D.5080409@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1157202680 4988 80.91.229.2 (2 Sep 2006 13:11:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 2 Sep 2006 13:11:20 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 02 15:11:18 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 1GJVHK-00059J-9S for ged-emacs-devel@m.gmane.org; Sat, 02 Sep 2006 15:11:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJVHJ-0007tO-P3 for ged-emacs-devel@m.gmane.org; Sat, 02 Sep 2006 09:11:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GJVH9-0007tB-7L for emacs-devel@gnu.org; Sat, 02 Sep 2006 09:11:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GJVH7-0007sr-KI for emacs-devel@gnu.org; Sat, 02 Sep 2006 09:11:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GJVH7-0007so-Dj for emacs-devel@gnu.org; Sat, 02 Sep 2006 09:11:05 -0400 Original-Received: from [192.114.186.73] (helo=heller.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GJVRB-0004Tx-Ve for emacs-devel@gnu.org; Sat, 02 Sep 2006 09:21:30 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-70-232.inter.net.il [80.230.70.232]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id AJC01113 (AUTH halo1); Sat, 2 Sep 2006 16:11:00 +0300 (IDT) Original-To: martin rudalics In-reply-to: <44F5D00D.5080409@gmx.at> (message from martin rudalics on Wed, 30 Aug 2006 19:51:09 +0200) 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:59252 Archived-At: > Date: Wed, 30 Aug 2006 19:51:09 +0200 > From: martin rudalics > CC: Stefan Monnier , emacs-devel@gnu.org > > Eli, please look at what your system tells you about the following two > Emacs files: "src/acldef.h" and "src/alloca.c". I get: > > Entries: /acldef.h/1.2/Mon Sep 1 15:45:52 2003// > Emacs: Mon Sep 1 17:45:52 2003 > Windows: Mon Sep 1 17:45:52 2003 > > Entries: /alloca.c/1.29/Fri Jan 30 17:10:02 2004// > Emacs: Fri Jan 30 17:10:02 2004 > Windows: Fri Jan 30 18:10:02 2004 > > Where Entries is the entry from CVS/Entries, Emacs is a prettified > version obtained from `file-attributes', and Windows is what WindowsME > tells me. I fail to understand why the values for `alloca.c' differ for > Windows and Emacs. Probably some mismatch in adjusting for the daylight saving offset; the URL I mentioned in my other message suggests some hints. > If these values are identic for you (XP I presume) than the problem > is with Emacs for Windows98/FAT32. See the URL I mentioned in my other message: yes, there's a difference between FAT and NTFS volumes in this respect. However, for a valid and meaningful comparison, the test cases you've chosen are not good enough. First, the actual time stamps of files in the local sandbox depend on the exact day one checks out the CVS tree and/or resyncs with it. Obviously, no two people do that on the same day; for example, my CVS tree was checked out in June 2005, so acldef.h bears a time stamp of June 18, 2005, which is very different from yours. It's impossible to compare times like this. I don't have any suggestions for how to make a meaningful comparison, though. There are too many system calls involved, and too many unknowns.