I was that poster -- or at least one of them -- and I stand by that recommendation. Broken builds are simply not acceptable in a team environment where everyone needs passing tests to move ahead with their work. That's what branch and merge are all about. If you want to dork around with the code and check in changes that break the build, create a temporary working branch and do all of that there.
My rule of thumb is never make a checkin to trunk that will break a build.
Even if you are not running continuous integration or are a single- person shop, branching is still a good habit to get into because you may need to expand your team size at some point and then continuous integration will greatly speed up your development process.
Quoting from the Agile Manifesto[1]
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
To deliver working software frequently, you have to keep the software working. Right?
[1] http://www.agilemanifesto.org/principles.html
On Mar 30, 2007, at 11:52 AM, shin kurokawa wrote:
BTW, to another poster recommending no commits until something is verified to work ------ That's asking for trouble. Even if unverified, you should commit regularly... just make sure to log useful information. Your repo will not inflate much for minute changes. Again, YMMV.