I've been reading Martin Fowler's note on Continuous Integration and he lists as a must "Everyone Commits To the Mainline Every Day". 

I do not like to commit code unless the section I'm working on is complete and that in practice I commit my code every three days: one day to investigate/reproduce the task and make some preliminary changes, a second day to complete the changes, and a third day to write the tests and clean it up^ for submission. I would not feel comfortable submitting the code sooner.

Now, I pull changes from the repository and integrate them locally usually twice a day, but I do not commit that often unless I can carve out a smaller piece of work.

Question: is committing everyday such a good practice that I should change my workflow to accomodate it, or it is not that advisable?

Edit: I guess I should have clarified that I meant "commit" in the CVS meaning of it (aka "push") since that is likely what Fowler would have meant in 2006 when he wrote this.

^ The order is more arbitrary and depends on the task, my point was to illustrate the time span and activities, not the exact sequence.

I commit code several times a day. Whenever I reach a point where the code is complete enough to compile and doesn't break other things, it goes in.

You should look at breaking up your work so you can safely check-in a few times a day.

The rationales for this are two:


Any work that is not checked in may be lost - your computer may have a catastrophic failure. In this case, the longer you wait, the more work you lose.
The more work you do without checking in, the more code others will need to integrate when you finally decide that it bakes. This introduces more chances of conflicts and merge issues.

