This is actually pretty serious and occurs surprisingly easily and often.  Especially IDE-users seem to fall for it, which is probably because the development environments are too smart and try to guess which files need recompiling and which don't.

You see, it is __very__ annoying when you check out the latest version of the code, and then start to code on your changes, only to find out that you can't compile other parts of the software, namely those that someone else modified.  Then you'll need to use your time to fix Someone Else's bugs, because if you don't, you can't do your own work.

A typical way of making this mistake is when you compile only parts of the code, but forget that your API changes might require changes in some other part of the code. Since you didn't compile that particular part, you never know it breaks.  Until someone calls you with a murderous gleam in their eyes.

There is only one really effective way against this: Recompile everything.  Run a make/ant clean, use your IDE, or delete the whole build directory, then recompile everything.  If it compiles, then you can check it in.  It's okay if it doesn't work (you can fix that later), as long as it does compile.

The other way is, of course [unit testing].  But that does require recompiling everything, too.

(I've heard that in some companies those who break the build get to wear a special "I broke the build" -hat until someone else breaks the build.  During the first few days, the hat travels around pretty rapidly.  After a while, you are stuck with it for days.)

__Don't break the build.  Recompile everything before you commit.__

''(Oh yeah, this of course works only when your project is small enough for recompilation.  Large projects like [Mozilla|] can easily take an hour to compile.  Any ideas on how to handle this?)''

I actually got so fed up with people at my work (including myself) unknowingly breaking the build that i created a Java program called Elijah that checks our source code control system (Perforce) every 45 seconds for checked in files, and if it finds any, it rebuilds the whole system (takes about 4 minutes currently). If that fails, it sends mail to the whole group, informing them that build is busted. (When the build is fixed again, it sends an "All Clear" email).

Secondly, there is a web page on this machine that, when served, checks to see if any files have been checked in since the last build, and if not, tells you that you can "Sync With Confidence!" This combo has 
worked much better than exhortations to always rebuild from scratch. Even better would be if it deployed, ran unit tests, etc...

I believe Mozilla handles this by constantly rebuilding with a tool called [Tinderbox|]. -- [MahlenMorris]

This practice is now commonly called [ContinuousIntegration]. On the linked page, I have added links to two open source tools that can be used to manage automated builds:

* Anthill
* ~CruiseControl

-- [PaulDownes], 11/21/02