This is sound advice, and generally should be followed. It works well
for medium sized changes.
However, requiring this for a simple one-liner fix might be overkill.
(And it's certainly unnecessary if one is only fixing the docs or a
comment in a source file.)
It works quite poorly for rather huge changes, such as Matt's work for
adding 64bit support.
First, looking at purely a practical standpoint, getting tests alone
to pass is not enough, if major new functionality is added. It becomes
necessary to think of and get brand new tests working as well. And then
fix bugs in those tests. And then perhaps new tests based on the bugs
found and fixed. And so on.
A related point is that it's quite common for a person to run the tests
on one platform, then do a commit, then learn that another platform
broke. It's quite an arduous task to test all platforms at once before
committing. In fact, it's still quite an arduous task to test all
platforms at once immediately after making a commit.
(The nature of hg is
a big help here, since one can "commit" from a working copy of one
platform directly to the working copy of another platform without
needing to go through the central "main" server. While it's possible to
later deliberately check out that commit and possibly get a broken
build, if done right one will never accidently do a routine pull &
update and get broken code - because when the finished code is pushed to
the main server, the commits for all the fixes are pushed at once,
Secondly, when making significant changes that occur all over the code
base, it often makes sense to group
lots of commits in stages. This way if you need to temporarily or
permanently back out a change, you still have a record of it.
It's also quite common, when implementing these sort of changes, to find
bugs, fix them, and then find regressions. It's useful to be able to use
the Revision Control System to compare older and newer versions of the
code to track down and fix the regressions in a way that won't cause the
original bug to reappear.
For that matter, using RCS to track this can make reverting a
particular given change (that's part of a much larger effort, e.g.
fixing integer() to deal with integers that are too big to fit in an
atom as part of the 64bit port) a lot easier.
(Of course, using branches helps out a lot with this. And hg's greater
flexibility with regard to branches (as compared with svn) is a big help
here. So is hg's ability to practically commit directly from working copy
Finally, it makes it a lot harder to invite other developers to look at
your changes and help track down potential bugs, or implement fixes for
bugs you've dicovered but want a second opinion on. (Of course,
branching more or less solves this issue. And once again, hg's
flexibility with branches, and ability to practically push changes directly
from one developer's working copy to another's, is significantly
So, in summary, I don't believe that having 100% of tests passing in the
development branch(es) is a particularly worthwile goal. To me, the
benefits don't really outweight the drawbacks. However, I do admit that
drawbacks are significantly lessened by the move from SVN to Hg.
On Thu, Feb 17, 2011 at 03:20:43PM +1100, Derek Parnell wrote:
> On Thu, 17 Feb 2011 14:58:38 +1100, Jim C. Brown
> <jbrown105@...> wrote:
> > 100% in trunk/head/default is rare (unless you have only a single
> > developer). I've only seen this in business
> > environments - and then only when the managers (whom lack programming
> > experience) mandate that the developers have to do this. Usually this
> > goes hand in hand the sort of corporate culture that requires one to
> > hold meetings to review and review and review code changes before being
> > allowed to actually make any changes.
> Or ... one only commits to repository once the changes pass the test suite.
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> Rapideuphoria-develop mailing list
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.