As many know, I'm a strong (tee-hee) advocate of version control. For everything. Code, of course, configuration files, my GNUCash datafile, etc. Basically, if it's important, and it's not several gigs of photos, music, or video, it's in version control. Seems like overkill for a lot of things, but at the very least, it allows me to back up my repository and get all my important data in one fell swoop.
One thing that I try very hard to be diligent about is the 'atomic commit'. That is to say, when you commit, you're committing exactly one change. It might be across a bunch of files, but it's one change. The reason is that if you later realize it was a bad choice for whatever reason, you need only do a reverse merge (merge -rN:N-1) to undo it. If you don't have an atomic commit, and you only want to undo part of what you committed, then you're stuck with doing that merge, but then undoing part of the merge, which gets really dicey if you've got some mods in a file that you want, and some mods that you don't. Ick.
I mention this because I wasn't diligent about this on two commits about 3 weeks ago. And of course, part of one of those commits needed to be rolled back yesterday, and it took the better part of 3 hours to do, instead of the expected 10-15 minutes. Version control is far too powerful of a tool to squander it's capabilities by being lazy when it comes time to check in.
Bonus points to anyone who got the joke I "laughed" about in the first sentence. ; )
Good points Barney. I also try to follow the atomic commit practice as well. Fortunately, I haven't had to rely on a rollback merge to undo a change, but it just seems to make sense to me to do commits once a feature/bug is fixed.