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]
