We have to bring in bagels and creamcheese for breaking the build. We go so long between build breaks these days, that we chip in and just buy treats anyways! :-)
>-----Original Message----- >From: Todd Pierce [mailto:[EMAIL PROTECTED]] >Sent: Thursday, February 06, 2003 4:35 PM >To: 'Struts Users Mailing List' >Subject: RE: [OT] how do people work in project with one CVS server > > >At our office we made build breaking a beerable offence, >payable as a round >of drinks to the entire development team. Nowadays NOBODY >breaks the build. > >-----Original Message----- >From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] >Sent: Friday, 7 February 2003 8:56 AM >To: Struts Users Mailing List >Subject: RE: [OT] how do people work in project with one CVS server > > > > >On Thu, 6 Feb 2003, ROSSEL Olivier wrote: > >> >> Another question i have. >> How do people using Eclipse or whatever handle the fact that >CVS don't >lock >> files, ie. allows for multiple simultaneous edit/save ? >> > >You can actually configure CVS to "lock" the files (allowing only one >person to check a file out for modification at a time), but >most CVS shops >I know would find that hopelessly restrictive. CVS also has >facilities to >merge changes (if it can) if conflicts occur. > >Struts itself, like all Apache software, is stored in a shared CVS >repository (you can even get anonymous CVS access to it by >following the >instructions at <http://jakarta.apache.org/site/cvsindex.html>). There >are many people that have commit access, and we operate with >no locking -- >yet there are very very few conflicts. Even when there are, >they tend to >be pretty easy to resolve. > >A couple of "development culture" issues help this to some degree: > >* We tend towards many relatively small commits, targeted at a > particular change (fix a single bug report, for example), > so you tend to touch relatively small numbers of files, > and touch the minimum number of lines in each of those > files. (This rule also helps keep the commit log that CVS > keeps for you more useful than it would be with, say, > all the changes for one day lumped in to one commit.) > >* We're often working on different aspects of the same > application, so we tend to be working on different > files anyway. (Good factoring of your code into small > reusable pieces helps too :-). > >* When there are large scale refactorings, and/or we're about > to do a release, we talk with each other and pause until the > large change is completed. > >* We have a basic agreement with ourselves that "thou shall not > break the build" -- you need to ensure that the entire package > compiles (for Struts, I use "ant clean dist") with your modified > code, before you check it in. > >* We tend to keep our local copies of the files refreshed (I do > "cvs update -dP" while my morning coffee is perking) so that, > when we're changing something, we're always starting from the > most recent version of the file. > >* We use the HEAD branch for the up-to-the-minute development (this > is where the nightly builds come from, too), and create a branch > for each major release so that you can go back and do maintenance > on it. There are some CVS tools for merging changes from one branch > back in to the other, if you find yourself making changes that need > to be ported to multiple versions. > >Every development team has to work out the "rules of the road" >for shared >resources. But these are some of the things that have helped us build >Struts. > >Craig > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
