Date: Wed, 4 Sep 1996 13:04:25 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Terry Lambert <terry@lambert.org> Cc: rkw@dataplex.net (Richard Wackerbarth), current@freebsd.org Subject: Re: Latest Current build failure Message-ID: <199609041904.NAA01512@rocky.mt.sri.com> In-Reply-To: <199609041757.KAA06834@phaeton.artisoft.com> References: <v02140b11ae528565806d@[208.2.87.4]> <199609041757.KAA06834@phaeton.artisoft.com>
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) > > > > 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? In my experience, 'copy-time' inconsistancies 'simply don't happen'. I've been grabbing the CVS tree via SUP/CVSup since day one, and I can count on *one* hand the # of times I've had problems with the 'copy' I've gotten that's been busted because of a checkin in progress. As stated, it's simply not a problem worth messing with. (BTW, early versions of CVS used a single 'write-lock' scheme, but after testing it was considered overkill hence the 'new' scheme which used directory-lock schemes.) A recent discussion of this point went on in devel-cvs. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609041904.NAA01512>