Dave Donaldson nails it again when he talks about checking in your changes as often as possible. I've seen people resist this because of a "that's not how I work" mentality, and when you work with Continuous Integration, that thought process doesn't work.

So how do you get developers past the "check files out all day" way? I find fear is a good motivator:

• You don't go home if the build is broken: Simple enough. If you check in bad code and it the build server doesn't like it, then you fix it before you leave for the day.
• Merging is your enemy! enable multiple checkouts in your source code repository. If you want developers to check in often and keep files checked out for the bare minimum amount of time, let them experience merging. Despite the fact that merging is usually a seamless process, it still strikes fear in developers hearts - at least enough to get them to check in often.

Seriously though, the main reason developers don't check in often is because they look at a feature and see that as their "unit of work" to check in all at once (or they look at a day as their unit of work). It's a learning process to realize that features can be broken down into smaller tasks that can be checked in. Dave states it pretty well.

It's really about small blocks of code that you know not only compiles on your machine but also on the build server. The code doesn't have to be functionally ready from a requirements perspective, but should do *something*

Once you realize this, it's much easier to check in often. On a typical development project, I check in every hour or so. Features aren't built in an hour (typically) but small tasks can be completed in that time, and it's advantageous to get them checked in as quickly as possible - if for no other reason than not having to merge!