Date: Tue, 5 Jul 1994 16:44:40 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes> To: nate@bsd.coe.montana.edu (Nate Williams) Cc: paul@isl.cf.ac.uk, cvs-all@freefall.cdrom.com Subject: Re: 2.0 access Message-ID: <199407052344.QAA25408@freefall.cdrom.com> In-Reply-To: <199407052334.RAA00711@bsd.coe.montana.edu> from "Nate Williams" at Jul 5, 94 05:34:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > [ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199407052344.QAA25408>