Date: Tue, 5 Jul 1994 18:12:15 -0600 From: Nate Williams <nate@bsd.coe.montana.edu> To: "Rodney W. Grimes" <rgrimes@freefall.cdrom.com> Cc: paul@isl.cf.ac.uk, cvs-all@freefall.cdrom.com Subject: Re: 2.0 access Message-ID: <199407060012.SAA01011@bsd.coe.montana.edu> In-Reply-To: "Rodney W. Grimes" <rgrimes@freefall.cdrom.com> "Re: 2.0 access" (Jul 5, 4:44pm)
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199407060012.SAA01011>