Date: Wed, 3 Oct 2001 09:30:53 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: stable@freebsd.org Cc: krentel@dreamscape.com Subject: Re: mod times after cvsup Message-ID: <200110031630.f93GUrG02145@vashon.polstra.com> In-Reply-To: <200110020645.f926jUZ43283@dreamscape.com> References: <200110020645.f926jUZ43283@dreamscape.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200110020645.f926jUZ43283@dreamscape.com>, Mark W. Krentel <krentel@dreamscape.com> wrote: > I just cvsup'd RELENG_4_4_0_RELEASE in preparation for buildworld, > and I noticed something odd about the modification times of some of > the files in /usr/src. And I don't mean the S1G, Dec 1969 bug. > > % cd /usr/src && ls -ld [A-Z]* > -rw-r--r-- 1 root wheel 4735 Sep 5 1999 COPYRIGHT > drwxr-xr-x 2 root wheel 512 Apr 15 23:23 CVS > -rw-r--r-- 1 root wheel 7486 Oct 1 01:28 Makefile > -rw-r--r-- 1 root wheel 26977 Sep 14 13:47 Makefile.inc1 > -rw-r--r-- 1 root wheel 9761 Aug 27 1999 Makefile.upgrade > -rw-r--r-- 1 root wheel 2642 Oct 27 2000 README > -rw-r--r-- 1 root wheel 35884 Sep 14 13:46 UPDATING > > The mtime on Makefile.inc1 is Sept 14, which is correct and matches > the time in the RCS Id. But the date on Makefile is Oct 1, the time > I cvsup'd. In the CVS repo, the date for the RELENG_4_4_0_RELEASE > version of /usr/src/Makefile should be April 25, which I can see from > http://www.FreeBSD.org/cgi/cvsweb.cgi/src. > > Feel free to whack me with a clue stick if I'm off base, but I thought > cvsup was supposed to preserve the mtime from the repo. The man page > says it does. The man page no doubt needs to be made clearer. CVSup intentionally doesn't preserve the mtime in checkout mode. It follows the same rules as CVS: - If it is creating a new file, it sets the mtime according to the time stamp of the relevant revision as recorded in the RCS file on the server. In other words, it sets the mtime to the same date and time you see when you run "cvs log" on the file and look at the entry for the revision that is checked out. - If it is updating an existing file, it simply "touches" the file by setting its mtime to the current date and time. Here is the reason for the second rule. Suppose there is a file "foo.c" in the source tree. You run CVSup on September 1, and this file is created with the timestamp of its latest revision -- say, August 15. The next day, you do a make buildworld, and foo.o gets an mtime of September 2, the current date. Then on September 15, for whatever reason, you blow away your /usr/obj tree and do another make buildworld with the same sources. So foo.o gets rebuilt with a new timestamp of September 15. Meanwhile, on September 7, somebody has made a commit to foo.c. You don't have it yet, because you haven't run CVSup. On September 30, you update your sources with CVSup and then run make buildworld again. If CVSup preserved foo.c's mtime according to the revision history, it would get an mtime of September 7, the date of the latest commit to that file. But your foo.o is newer than that (September 15). So (ignoring the make clean step which is implicit in FreeBSD's make buildworld but is not generally performed in other software projects), make won't know that foo.o needs to be rebuilt. Because of this problem, both CVS and CVSup touch the mtimes of updated checked-out files rather than setting the mtimes according to the revision history. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110031630.f93GUrG02145>