From owner-freebsd-current Tue Jul 8 15:20:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA12521 for current-outgoing; Tue, 8 Jul 1997 15:20:25 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA12504 for ; Tue, 8 Jul 1997 15:20:18 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id PAA28704; Tue, 8 Jul 1997 15:20:04 -0700 (PDT) Message-Id: <199707082220.PAA28704@austin.polstra.com> To: fenner@parc.xerox.com Cc: current@FreeBSD.ORG, bde@zeta.org.au, ache@nagual.pp.ru, peter@spinner.dialix.com.au Subject: Re: CVS Branches hits again! Date: Tue, 08 Jul 1997 15:20:03 -0700 From: John Polstra Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This is cvsup not being bug-compatible with cvs. These files really > were brought back from the dead, but cvs doesn't check them out > because it left them in the Attic. Bill is right, but it's even worse than that. CVS is not even bug-compatible with CVS. For example, if you do a "cvs export -D tomorrow src/usr.bin" you do not get the same files as you get when you do a "cvs co -P src/usr.bin". The export command brings back the files that were erroneously killed on the vendor branch and then followed by a new import. "cvs co -P -D tomorrow src/usr.bin" does the same thing, even though the "-D tomorrow" shouldn't affect which files are checked out. Furthermore, if you do a "cvs co -P src/usr.bin" and then cd src/usr.bin/bdes cvs status bdes.c it says "Needs Checkout". > The repository needs to be fixed Yes, the repository needs to be fixed. It is a big mess. People who are busily importing lite2, please stop until this can be taken care of. Or at least trim out the files that have been removed from our source tree. I have a "fixed" cvsupd which behaves more like CVS and which will buy us some time. As soon as I test it a little bit more, I'll get it deployed on as many mirrors as I can. Luckily, the change is in the server and not in the client. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth