On Mon, Dec 09, 2002 at 05:58:46PM -0800, Noel Yap wrote:
> It sounds to me that there's a very large chance that
> peoples' builds break due to the "Checkin Often" and
> the "Update Often" policies. How do you resolve this?
You hurt people when the build doesn't work. :-) Where I am, we have a
very strong social incentive not to break the build: that is, you get
called names, made to buy doughnuts for the team, and generally mocked.
If the tree won't even compile it gets fixed almost immediately by
whoever notices first. If it fails some tests then that often takes
longer but will be fixed in due course too. We have an internal web page
displaying rolling build and test results which all the developers keep
an eye on reasonably frequently. It works.
People update regularly enough out of a combination of habit, interest
in what's changed recently, and the fact that you can't check your own
changes in if you're out of date.
(This is with Perforce; I don't actually know offhand whether it has
watches. You do have to 'p4 edit' before starting work on files, and it
does warn you if somebody else is editing the file, that's true, but we
never really pay any attention to this.)
> Where I am currently, broken builds occurred so often
> that I updated only when I was sure the build works
> (no more than once every other day).
This sort of thing can be dealt with, but it has to be done
systematically; and the problem is really one that your version control
system and policies are making more obvious, not one that they're
causing. Namely, if everyone treats a working build as their
responsibility, releases become much less effort, and everyone becomes
more efficient in the long run.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 10 03:24:46 2002