Date: Sat, 06 Oct 2001 01:31:39 -0400 From: "Mark W. Krentel" <krentel@dreamscape.com> To: jdp@polstra.com Cc: freebsd-stable@freebsd.org Subject: Re: mod times after cvsup Message-ID: <200110060531.f965Vdi48717@dreamscape.com>
next in thread | raw e-mail | index | archive | help
> 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.
OK, that makes sense. Certainly a pitfall to avoid. I guess I don't
cvsup often enough and my memory is going. :-)
But I'm still puzzled by the following. I cvsup src-base (just six
files) with tag=RELENG_4_2_0_RELEASE into an empty, temp directory and
I get this:
-rw-r--r-- 1 root wheel 4735 Sep 5 1999 COPYRIGHT
-rw-r--r-- 1 root wheel 7257 Nov 7 2000 Makefile
-rw-r--r-- 1 root wheel 24600 Nov 11 2000 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 30679 Nov 16 2000 UPDATING
Fine, but now I change tag=RELENG_4_4_0_RELEASE and I get:
# cvsup -g -L 1 src-base
Connected to cvsup12.freebsd.org
Updating collection src-base/cvs
Edit src/Makefile
Checkout src/Makefile.inc1
Checkout src/UPDATING
Finished successfully
-rw-r--r-- 1 root wheel 4735 Sep 5 1999 COPYRIGHT
-rw-r--r-- 1 root wheel 7486 Oct 5 22:08 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
Why did it edit Makefile but checkout new copies of Makefile.inc1 and
UPDATING? All of those files previously existed. And by setting the
mtime for UPDATING to Sep 14, there's the possibility of the above
pitfall you describe. Well, not for UPDATING because it's not a
dependency in a Makefile, but it could if the file was updating.c.
Digging a little deeper into the CVS repo from the cvsweb.cgi script,
it appears the problem is that the RELENG_4_4_0_RELEASE versions of
Makefile.inc1 and UPDATING are not on the RELENG_4 branch. For
Makefile.inc1, rev 1.141.2.16 is on branch RELENG_4 and also has tag
RELENG_4_2_0_RELEASE. But rev 1.141.2.31.2.1 with tag
RELENG_4_4_0_RELEASE is on branch RELENG_4_4 with no mention of
RELENG_4. So, the server doesn't know that RELENG_4_4_0_RELEASE
and RELENG_4_2_0_RELEASE are on the same RELENG_4 branch.
I have yet to find a C file with this behavior. But with increased
use of RELENG_4_4 and RELENG_4_5, could this become a problem?
--Mark
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?200110060531.f965Vdi48717>