I do not agree with this rule and I agree with what Mason Wheeler said. I would
like to add a few ideas.
I try to commit every time I have a meaningful
change to commit: this can be several times a day if I fix several small bugs,
or once a week if I am working on a larger piece of software that cannot be
used by the rest of the code in any meaningful way until it reaches a
consistent state.
Also, I interpret committing as publishing a meaningful revision that
contributes new functionality to the code base.
I think one should try to clean up the code before committing so that
other developers can understand the meaning and the purpose of the change
when they look at the revision history. The fewer changes other developers
see in the history, the better: when I look at the revision history I want
to see increments that add some meaningful functionality; I am not interested
in every small idea each developer had and wanted to try out before they
reached the solution.
Furthermore, I do not think it is a good idea to use the SVN server
(or whatever version control system) as a backup facility to which
the current snapshot of the code is committed (provided that it compiles):
you can use a USB stick or an external USB-drive or a network disk
to mirror your current code so that it does not get lost if your
computer breaks down. Revision control and data backup are two different
things. Publishing a revision is not the same as saving a snapshot
of your code.
Finally, I think that it should not be a problem to commit every now
and then (i.e. only when one is really satisfied with the current state of
the code) and avoiding merge conflicts is not a good justification for
committing (too) often.
Many merge conflicts happen when different people work on the same files
at the same time, which is a bad practice (see e.g. this article, point
7).
Merge conflicts should be reduced by splitting a project into modules with
clear interfaces and as few dependencies as possible, and by coordinating
the work of developers so that the code they work on overlaps as little
as possible.
Just my 2 cents.
EDIT
Another reason against premature commits that came to my mind is that
a (very) buggy version cannot be tested. If you are committing on the trunk
and your test team is testing every day, they might have no testable version
for a few hours (or for a day). Even if you do not try to fix the bug and
just revert your changes, a rebuild can take a couple of hours. With, say,
five testers working in your team, you have wasted 5 x 2 = 10 hours of
the team's time due to inactivity. It happened to me once so I really try
to avoid premature commits in the name of commit as soon as possible.