From owner-freebsd-current Wed Sep 4 10:58:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA23752 for current-outgoing; Wed, 4 Sep 1996 10:58:59 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA23744 for ; Wed, 4 Sep 1996 10:58:56 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA06834; Wed, 4 Sep 1996 10:57:09 -0700 From: Terry Lambert Message-Id: <199609041757.KAA06834@phaeton.artisoft.com> Subject: Re: Latest Current build failure To: rkw@dataplex.net (Richard Wackerbarth) Date: Wed, 4 Sep 1996 10:57:09 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.org In-Reply-To: from "Richard Wackerbarth" at Sep 3, 96 08:05:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >Actually, you could seperate the process using a covert channel for the > >checkout for the build server: > > > >2) copy active cvs tree on repository to statis cvs tree on > > build server > >5) copy successfully test-built static cvs tree on build server > > to distribution cvs tree on distribution server (could be > > the same machine, the repository, or could be a third machine) > > As I have said, we don't need to worry about the distribution of "cvs" > trees. If I have such a tree, I can check out the (redefined) "current" > distribution without worrying whether or not it is the "head" or if "head" > is buildable at the present time. > > What we need to "limit" is the access known as "current". Updates of that > version would be subject to the "buildability" test. How can you tell the difference between a copy-time inconsistency that results from a copy interleaving with a checkin process, as opposed to an artifact in the cvs tree itself causing the inconsistency? This is, in fact, my problem with the "token/vote" scenario. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.