From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: vc-cvs-parse-entry Date: Mon, 11 Sep 2006 10:14:36 -0400 Message-ID: References: <44F4A8D0.6090304@gmx.at> <44F5D00D.5080409@gmx.at> <44F98B06.2020602@gmx.at> <44FAB10B.8010608@gmx.at> <44FBEF1E.8030806@gmx.at> <44FD3EFC.9040603@gmx.at> <4503E115.4020206@gmx.at> <45052F41.5010501@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1157984108 28384 80.91.229.2 (11 Sep 2006 14:15:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 11 Sep 2006 14:15:08 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 11 16:15:05 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 1GMmYq-0006Fe-Se for ged-emacs-devel@m.gmane.org; Mon, 11 Sep 2006 16:14:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMmYq-0000KF-9K for ged-emacs-devel@m.gmane.org; Mon, 11 Sep 2006 10:14:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GMmYc-0000Hl-VX for emacs-devel@gnu.org; Mon, 11 Sep 2006 10:14:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GMmYZ-0000FL-TR for emacs-devel@gnu.org; Mon, 11 Sep 2006 10:14:41 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GMmYZ-0000FI-PE for emacs-devel@gnu.org; Mon, 11 Sep 2006 10:14:39 -0400 Original-Received: from [209.226.175.54] (helo=tomts10-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GMmZp-0000HI-I0; Mon, 11 Sep 2006 10:15:57 -0400 Original-Received: from localhost ([70.55.143.66]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060911141437.RCJQ13241.tomts10-srv.bellnexxia.net@localhost>; Mon, 11 Sep 2006 10:14:37 -0400 Original-Received: by localhost (Postfix, from userid 20848) id E21B96C1C7; Mon, 11 Sep 2006 10:14:36 -0400 (EDT) Original-To: martin rudalics In-Reply-To: <45052F41.5010501@gmx.at> (martin rudalics's message of "Mon\, 11 Sep 2006 11\:41\:21 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:59682 Archived-At: > I did "cvs co" on March 24, 2005. I did not count the "cvs up" I did > since then, the last one was a week ago. Can you explain how dates in > the range from 1999 till 2004 made it to my Entries? IMHO, these dates > must reflect the corresponding dates in the repository. Indeed, when you do `cvs co', cvs manually sets the mtime of the files it creates to match the time when they were committed. After that, cvs doesn't fiddle with the mtime any more (i.e. the mtime does reflect the time at which the file was later updated). > This, of course, includes the case where (as in <"An example of the > problem">) a file is created in one DST season and is then read from the > opposite DST season (for example, create a file in summer (which > effectively sets a summer file time from summer) and then read it from > winter), but it also includes hitherto unseen cases in which > FindFirstFile() will even return the wrong time for a file time in the > same DST season as the current system time if the file time was set from > the opposite DST season to the current system time (for example, set a > summer file time from winter and then read it from summer). Also note > that, in other thus-far unseen cases, FindFirstFile() can return the > correct time for a file time in the opposite DST season to the current > system time if the file time was set from the same DST season as the > current system time (for example, set a winter file time from summer and > then read it from summer). Indeed, that's why it's hopeless: just do `cvs update' and get on with your life. Stefan