From owner-freebsd-current Sat Dec 23 22:59:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA06627 for current-outgoing; Sat, 23 Dec 1995 22:59:04 -0800 (PST) Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA06622 for ; Sat, 23 Dec 1995 22:59:00 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id OAA13537 for freebsd-current@freebsd.org; Sun, 24 Dec 1995 14:58:54 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 24 Dec 1995 14:58:50 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <4bitna$d6q$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199512230435.PAA07671@godzilla.zeta.org.au>, <199512230438.UAA00172@corbin.Root.COM> Subject: Re: cvs fails to remove no-longer-present files Sender: owner-current@freebsd.org Precedence: bulk davidg@Root.COM (David Greenman) writes: >>The new cvs apparently has a bugfeature of checking out old things from >>the Attic when there are references to the old things in CVS/Entries >>This is inconsistent with the old cvs, and breaks ctm, which doesn't >>export CVS/*. > Oh! I haven't switched to using the new cvs yet...that explains it. > Peter? >-DG The death support code in the new cvs is getting tripped up because we are writing the repository with the old cvs. The new cvs creates the files in a way that is totally backwards compatable with the old cvs, but it's not perfect the other way around. With cvs-1.5 and later, the state of the file is stored in the state field: 1.1 date 94.06.22.06.57.25; author peter; state Exp; ^^^^^^^^^^ Since files can now be added and removed over and over again without having Attic conflicts, the new cvs has to go purely on the "state" of the revision it is dealing with rather than the global "Attic" state. Specifically... Under old cvs, if somebody does a 'cvs rm' on a file on the HEAD, it is moved to the Attic - this is a global change. If you do an 'cvs update -r yesterday' your tree will no longer build because the file was not recovered. However, with the new cvs writing the repository, this does exactly what you'd expect.. If you did an 'update -r yesterday' (and the file was only just removed), the file will reappear again. When you do the 'update -A' it will disappear again. This is useful for things like in -current at the moment, where i386/conf.c is about to be removed. Once it is gone, under the old cvs, it will no longer be possible to do a 'cvs update -r "december 1st"' and get a buildable system. The "fix" is to install cvs from -current on freefall. This is overdue.. I've just made the changes on freefall to enable it to be compiled there... -Peter