From owner-freebsd-chat Mon Dec 9 14:53:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA07491 for chat-outgoing; Mon, 9 Dec 1996 14:53:03 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA07481 for ; Mon, 9 Dec 1996 14:53:00 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA01956; Mon, 9 Dec 1996 15:28:50 -0700 From: Terry Lambert Message-Id: <199612092228.PAA01956@phaeton.artisoft.com> Subject: Re: siguing into current from a random version To: j@uriah.heep.sax.de (J Wunsch) Date: Mon, 9 Dec 1996 15:28:50 -0700 (MST) Cc: chat@freebsd.org, terry@lambert.org In-Reply-To: <199612092107.WAA24141@uriah.heep.sax.de> from "J Wunsch" at Dec 9, 96 10:07:30 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-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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). > > Do the global writer locks compile the tree for me? Then i'm all for > it! :-) > > Otherwise: moot point, i'd say... I can barely remember that we've > been suffering from two people hammering at the tree at the same spot, > and causing inconsistencies by this. 99.9 % of the problems have been > human errors. I agree. The problem is to eliminate the possibility for human error. Right now, if the tree won't compile after person A has touched it, person A can say: o "Not my fault, person B was touching at the same time, and the changes were interleaved" (finger pointing) o "Not my fault, you supped it while I was checking in" (it is the fault of the person who got the code, not that of the person who provided it) o "Phase of the moon" (can not be disproved because the line between 'compilable' and 'non-compilable' is fuzzy) The point of locks is *not* to keep developers from stepping on each other. The point *is* to eliminate all of the convenient excuses everyone habitually use to claim "not my fault" when the tree breaks. Until you can assign fault, you can't demand reparations. *IF* the developers follow the protocol (they have to follow *a* protocol to checkin anyway), then the exported copy of the cvs tree will be buildable, always. Committers can not use the "it is the fault of the person who got the code" argument. *IF* the users sup/ctm/whatever the exported copy of the cvs tree, then the tree people download will be buildable, always. *IF* a spanning set of changes is labelled, then it is easier to back out something that breaks the tree until the offending committer does something about it and recommits, without screwing everyone else up. Committers can not use the "phase of the moon" argument. *IF* committers are not allowed to interleave their commits (a rare occurance, even as you admit, and therefore not a hardship for the developers), *THEN* committers can not use the "finger pointing" argument. Voila, we have destroyed all of the rocks behind which tree-breakers can hide. If person A breaks the tree, it will be obvious that it is person A's fault, and the breakage can always be trivially undone by backing up one write-lock-label. I still claim that this is a worthwhile thing to do. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.