Just to add two more recommendations to Craig's list: * Have an automated build process that builds from scratch and runs your tests. Run this process at least once a day (cf. the nightly build process for Struts and other Jakarta projects.) This ensures that if someone does "break the build", it gets detected quickly. We run builds hourly.
* In our case, we also have a developer "build" account which developers can log into and kick off a build. Most of us get in the habit of running a build from this account just after we check in. It catches all those annoying "oh, forgot to check in a file" and other issues that arise because your development machine is slightly different than the standard (and then you scramble to fix the build before anyone notices and you have to buy the beer!) -Peter On Thu, 2003-02-06 at 16:56, Craig R. McClanahan wrote: > > > 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]
