Date: Tue, 3 Sep 1996 14:29:30 -0500 From: rkw@dataplex.net (Richard Wackerbarth) To: Terry Lambert <terry@lambert.org> Cc: current@freebsd.org Subject: Re: Latest Current build failure Message-ID: <v02140b0aae522eaf209b@[208.2.87.4]>
next in thread | raw e-mail | index | archive | help
>I think a more reasonable, one machine, version would be: > >1) wait some interval >2) copy active cvs tree to static cvs tree >3) test-build static cvs tree >4) if test-build fails, go to 1 >5) copy successfully test-built static cvs tree to distribution > cvs tree >6) people download distribution cvs tree > > >Posits: > >a) the interval in step 1 should be as short as step 3 allows >b) access to the distribution cvs tree should be blocked > during step 5; this could be implemented with a simple > access lock protocol obeyed by the copy process and the > download process(es) >c) we would prefer to block modification by programmers to > the active cvs tree during step 2 to ensure an increased > likelihood of buildability; a reader/writer lock would > provide a guarantee here -- note, again: the guarantee > is not necessary, only desirable >d) assuming locing protocols, it's possible to split the > process once per additional build machine, as a divisor > into the interval in step 1: this could reduce the overall > turnaround time between an active tree modification becoming > available I think we can use existing mechanisms in this scheme. A) Anyone who has the cvs tree can sync and extract what they wish at any time after a snapshot timestamp. A cookie service simply needs to notify them of the validated timestamps. Therefore replace "cvs tree" with "current tree" in the above discussion and use a validation timestamp distribution for step #5. B) Step #2, can be triggered either by serial number on the existing ctm distribution of the cvs tree or by free running "trial timestamp" generators. If you wish to apply locking, the trial timestamp generator would be the only mechanism that needs to participate. The advantage of this is that Condition (b) is handled by the servers locking out access while they apply the ctm update. The ctm generator for "current" is just a client of the timestamp service. When it receives a valid timestamp, it generates a new output. WRT "current", the servers can use the ctm distribution. I think that, in general, those updates would be faster than a new "checkout" of the entire tree. A side benefit is that someone could then use "sup" to get back in sync with ctm distributions. Condition (b) is handled by the servers locking out access while they apply the update.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02140b0aae522eaf209b>