Date: Wed, 4 Sep 1996 10:57:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rkw@dataplex.net (Richard Wackerbarth) Cc: terry@lambert.org, current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <199609041757.KAA06834@phaeton.artisoft.com> In-Reply-To: <v02140b11ae528565806d@[208.2.87.4]> from "Richard Wackerbarth" at Sep 3, 96 08:05:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609041757.KAA06834>