On Fri, Jan 28, 2011 at 07:59, Ted Byers
I would prefer a model where there is a highly developed suite of test code (actually, I find it is often best if one begins with the tests first - but sometimes that is not practical), unit tests, integration tests and usability tests, and nothing gets checked in unless the code base plus the new code not only compiles, but the developer can show that with his implemented changes, the system still passes all tests. [...] In my practice, no member of my team commits anything until we know it works with everything already in the repository - no exceptions. This means that sometimes a programmer will work on an assigned task for days, or even a week, without commiting changes to the repository.
In such an environment, a DCVS is *more* useful, not less. Your process overloads commits with an extra meaning of validation. With a DCVS, team members commit as often as is helpful for their personal work, without affecting others. Then the validation can be run in parallel, and only pushed to the anointed repo once the validation passes. It avoid the downtime imposed by requiring code review or CITs that occurs when you can't check things in because they haven't passed the process, but nor can you keep working on things since there's no nice way to commit something other than your working copy. (In git, for example, you've checked in the changes, and all you need to send is your box's name and the hash of the commit to others -- be it the code review alias, the automated test suite runner, or the person responsible for the official build.) I've spent time trying to work with another dev on a feature at a company with a strict "code review before checkin" policy, and the lack of source control -- since you can't check anything in anywhere -- makes it a terrible experience.