How often should you commit?
More frequent commits are generally a good idea. This way, each revision has smaller changes, and it'll be easier to remove those changes later should you need to. (Although we didn't talk about it, SVN has a command that lets you roll back previous changes made to a file. If you need that, come talk to me and I'll show you how it works.) If, however, you have several changes in one big revision, you can't roll any of those changes back separately.
That said, there are limits. A good rule of thumb is that you should never commit anything that doesn't compile. If you do, and it's right before you go out of town for a week, and your partner updates right after you leave, then he's stuck until you get back.
Some teams in industry even require you to pass all of your test cases before you commit, although I think this is a bit too stringent. (A good happy medium seems to be requiring that all commits compile, then automatically running the test cases. A failed test case doesn't block the commit notification, but the test infrastructure can send out an email alert about the failed tests.)