From owner-cvs-all Tue Jul 5 11:52:16 1994 Return-Path: cvs-all-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id LAA14535 for cvs-all-outgoing; Tue, 5 Jul 1994 11:52:16 -0700 Received: (from rgrimes@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id LAA14528 for cvs-all; Tue, 5 Jul 1994 11:52:15 -0700 From: "Rodney W. Grimes" Message-Id: <199407051852.LAA14528@freefall.cdrom.com> Subject: More screwey test messages... To: cvs-all Date: Tue, 5 Jul 1994 11:52:14 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 301 Sender: cvs-all-owner@freefall.cdrom.com Precedence: bulk Seems I had some small file owner ship problems and thing where not getting archived.. this should have fixed it :-).. sorry for the wasted mail.. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-cvs-all Tue Jul 5 16:32:02 1994 Return-Path: cvs-all-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id QAA24696 for cvs-all-outgoing; Tue, 5 Jul 1994 16:32:02 -0700 Received: from bsd.coe.montana.edu (bsd.coe.montana.edu [153.90.192.29]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id QAA24686; Tue, 5 Jul 1994 16:31:53 -0700 Received: (nate@localhost) by bsd.coe.montana.edu (8.6.8/8.3) id RAA00711; Tue, 5 Jul 1994 17:34:49 -0600 Date: Tue, 5 Jul 1994 17:34:49 -0600 From: Nate Williams Message-Id: <199407052334.RAA00711@bsd.coe.montana.edu> In-Reply-To: "Rodney W. Grimes" "Re: 2.0 access" (Jul 5, 10:04am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Rodney W. Grimes" , paul@isl.cf.ac.uk (Paul) Subject: Re: 2.0 access Cc: cvs-all@freefall.cdrom.com Sender: cvs-all-owner@freefall.cdrom.com Precedence: bulk [ Doing updates from a sup'd CVS tree ] > No, simpler than that (or at least less network traffic). Since you > have a local updateable copy of the cvs tree, you simple ncvs co src > into /usr/src on your box and run ncvs updates on it after any sup ( > suggest you do it in the same cron job if you use cron to sup with). Actually, I suggest NOT doing that since you may over-write work-in-progress. That way you can update at will and bring in only those changes you feel you can test. I only update at points where I feel I can devote the time to testing/fixing the bugs, otherwise it just 'queues' the changes into the CVS tree for later update. This allows allows me to beat the snot out of certain things on the system and test them against a known release (source and binary) w/out losing track of the important incremental changes that are un-related to my project. > Some notes about all of this: > > 1. I have been using a model very similiar to this since March. It > works and works well. And I long before that. Most of my work over a year ago was done with this model. > 3. There should never be a case where a whole file is brought back to > freefall and commited over existing work. We have on several occasions > had major screw ups in the sources do to someone submitting a patched > up version of an older file for inclusion into the release, and then > blindly commiting the ``fixed but older'' file over the top of -current. I would disagree with this when the new file is bigger than the diffs, but that's picking nits. Nate From owner-cvs-all Tue Jul 5 16:44:44 1994 Return-Path: cvs-all-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id QAA25421 for cvs-all-outgoing; Tue, 5 Jul 1994 16:44:44 -0700 Received: (from rgrimes@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id QAA25408; Tue, 5 Jul 1994 16:44:41 -0700 From: "Rodney W. Grimes" Message-Id: <199407052344.QAA25408@freefall.cdrom.com> Subject: Re: 2.0 access To: nate@bsd.coe.montana.edu (Nate Williams) Date: Tue, 5 Jul 1994 16:44:40 -0700 (PDT) Cc: paul@isl.cf.ac.uk, cvs-all@freefall.cdrom.com In-Reply-To: <199407052334.RAA00711@bsd.coe.montana.edu> from "Nate Williams" at Jul 5, 94 05:34:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3205 Sender: cvs-all-owner@freefall.cdrom.com Precedence: bulk > > [ Doing updates from a sup'd CVS tree ] > > No, simpler than that (or at least less network traffic). Since you > > have a local updateable copy of the cvs tree, you simple ncvs co src > > into /usr/src on your box and run ncvs updates on it after any sup ( > > suggest you do it in the same cron job if you use cron to sup with). > > Actually, I suggest NOT doing that since you may over-write work-in-progress. cvs will never destroy work in process, if a conflict occurs your orignal file is saved as .#filename.version. If you want to get back you just move this file back to filename. > That way you can update at will and bring in only those changes you feel > you can test. This is an option, but one a user needs to make for himself, realize in the new MO something is tested and reviewed by one other person before it is commited, thus there should be no real reason for a developer NOT to update there source. > I only update at points where I feel I can devote the time to > testing/fixing the bugs, otherwise it just 'queues' the changes into the > CVS tree for later update. We need to fix the mode of operation that is causing you to do this, it is not a good model of developement. The code should be tested and REVIEWED before being commited. I think those 2 things would go miles for decreasing our ``committed bug'' problem. > This allows allows me to beat the snot out of certain things on the system > and test them against a known release (source and binary) w/out losing > track of the important incremental changes that are un-related to my > project. Your not being a FreeBSD developer, you haven't been in that mode for quite some time do to other things you are busy with. My proposal is for active developers, not active users :-). > > Some notes about all of this: > > > > 1. I have been using a model very similiar to this since March. It > > works and works well. > > And I long before that. Most of my work over a year ago was done with > this model. Yes, that is correct, Nate is probably the longest standing supper of the cvs tree, almost from day 1. > > 3. There should never be a case where a whole file is brought back to > > freefall and commited over existing work. We have on several occasions > > had major screw ups in the sources do to someone submitting a patched > > up version of an older file for inclusion into the release, and then > > blindly commiting the ``fixed but older'' file over the top of -current. > > I would disagree with this when the new file is bigger than the diffs, but > that's picking nits. Even when the diff is bigger it is better to take it over instead of the file, otherwise you could potential commit over the top of some one elses work. This has happen far to many times in the past and we really must start to change some things to stop it from ever happening again. There is no real good reason that this type of commit should occur. In most cases a simple checking of the $Id$ string would have prevented many of them. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-cvs-all Tue Jul 5 17:10:42 1994 Return-Path: cvs-all-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id RAA28393 for cvs-all-outgoing; Tue, 5 Jul 1994 17:10:42 -0700 Received: from bsd.coe.montana.edu (bsd.coe.montana.edu [153.90.192.29]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id RAA28327; Tue, 5 Jul 1994 17:09:52 -0700 Received: (nate@localhost) by bsd.coe.montana.edu (8.6.8/8.3) id SAA01011; Tue, 5 Jul 1994 18:12:15 -0600 Date: Tue, 5 Jul 1994 18:12:15 -0600 From: Nate Williams Message-Id: <199407060012.SAA01011@bsd.coe.montana.edu> In-Reply-To: "Rodney W. Grimes" "Re: 2.0 access" (Jul 5, 4:44pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Rodney W. Grimes" Subject: Re: 2.0 access Cc: paul@isl.cf.ac.uk, cvs-all@freefall.cdrom.com Sender: cvs-all-owner@freefall.cdrom.com Precedence: bulk > cvs will never destroy work in process, if a conflict occurs your orignal > file is saved as .#filename.version. If you want to get back you just > move this file back to filename. Yes, but I'd rather not have to do that. I'm basically a very lazy person at heart. > > That way you can update at will and bring in only those changes you feel > > you can test. > > This is an option, but one a user needs to make for himself, realize > in the new MO something is tested and reviewed by one other person > before it is commited, thus there should be no real reason for a > developer NOT to update there source. And as everyone is well aware, good ideas don't always pan out. What I do is this: 1) Start hacking 2) Bring in changes I don't think affect my code. 3) Finish hacking. 4) Test code 5) CAREFULLY bring in those changes into the tree that I think may conflict and test those separately. 6) Commit tested changes to the tree. Unfortunately, I've not done it as much as I'd like, but when I did the results were very positive. > > I only update at points where I feel I can devote the time to > > testing/fixing the bugs, otherwise it just 'queues' the changes into the > > CVS tree for later update. > > We need to fix the mode of operation that is causing you to do this, > it is not a good model of developement. The code should be tested > and REVIEWED before being commited. I think those 2 things would go > miles for decreasing our ``committed bug'' problem. See above. Nate