Each check in should consist of no less or more than a small number of complete features.
For example, you are about to add feature XYZ to your program. You've already tested it and know exactly what change you are going to make (no experimenting on production code)
1. Update your local repository from your version control system
2. Make your changes
3. Get it to compile, pass tests etc.
4. Check in to the version control system. As a comment describe the change in functional language (what the change achieves), and perhaps include especially important things that other developers should be aware of. You don't need to include minute detail as this can be gotten much more accurately using a diff tool.
TortoiseSVN allows you to see what files have changed and diffs of the code chages you are making. I use this to write my comments, and I scan the changes to ensure I am not accidentally making changes I don't intend to, and to reverse unnecessary changes, like inserted blank lines that weren't intentional (this keeps the repository diffs meaningful and concise)
This way, each revision represents the system at a meaningful point.
