Date: Mon, 9 Dec 1996 11:50:38 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@root.com Cc: ggm@connect.com.au, chuckr@glue.umd.edu, freebsd-current@FreeBSD.ORG Subject: Re: siguing into current from a random version Message-ID: <199612091850.LAA01028@phaeton.artisoft.com> In-Reply-To: <199612090141.RAA04389@root.com> from "David Greenman" at Dec 8, 96 05:41:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >I suppose an assumption many neophytes like myself make is that CVS commits > >happen to complete sets of *tested* changes and not work in progress, so that > >the worst-case state is the testing (by author/cvs-changer) didn't cover for > >ones own particular setup and circumstances. > > That's the ideal, but we all make mistakes. Heh. Like checking code in without compiling the tree as it would look following the checkin... Nothing you can do about that, really, without instituting global writer locks on the tree (not that this will ever be approved). If you wanted all checkouts to result in a tree with a self-consistent state, you would have to have reader-locks so a write couldn't come in while a checkout was in progress and screw up self-consistency. Alternately, you'd make a copy of the tree 3-4 times a day with a reader-lock, and unless you were on a hot check-in run, use the copy of the tree for builds. Otherwise, you'd set reader locks for local checkouts. checkin, main tree: lock w cvs update build [ modify code on build fail, rerun build, repeat as needed ] cvs ci unlock update, main tree (or tree copy for cvssup, sup, ctm, etc.): lock r cvs update (or copy tree, whatever) unlock update, copy-of-main tree (or actual SUP client, etc.): cvs update (or copy tree, whatever) o copy-of-main tree is guaranteed buildable. Period. o main tree is guaranteed buildable if either lock has been asserted and a cvs update/build/checkin cycle has been successfully completed in the last writer lock cycle. Sure, someone could intentionally "unlock" a broken tree, but whoever did it would be signing their name in blood on the thing, for all to see. o ulockw can be used to create a "global log file" with delatas for overall changes. In addition, session tagging can be used to return tree to previous self sconsistent state for each and every checkin I know, I know: locking has been shouted down as inconvenient (even if integrated in encapsulation programs, ala): cvs lock r cvs update (or copy tree) cvs unlock (you would encapsulate by allowing only root/group write access to the archive, no one would be a member of the group, and cvs lock r would be suid root and add group access for the group to the current process on lock and take it away on unlock). Kinda like seatbelts... everyone complains about inconvenience with them, too. Regards, 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?199612091850.LAA01028>