Lingering check-outs: Increasing VS Build Stability

For those of you who use the checkout-modify-checkin method of source code control within Visual Studio (I.e. many Visual Source Safe users) here's some advise to increasing integration ease and build stability between developers and a build system.

As you start to share more VS projects, it's important to be aware of what you have checked out, particularly the project files. When adding items, if you check in the project file, but not the new item itself, the project will not build because of the missing item in source control. However, if you leave the project file checked out while you work on the new item, another developer won't be able to checkout the project to modify it or add items to it because of your exclusive checkout. What will often happen is that one developer is in the process of building the new item when someone else needs to work with the project. So the first developer checks in both the project and the new item. However, the other developer still can't build the project due to the half finished item. This leads to wasted time while the unfinished, breaking code is commented out and checked in. This results in confusing noise in source file history.

The best way of avoiding this scenario is to keep project files checked in as much as possible. My experience has shown the following process for adding items to projects to be most affective:

- Let Visual Studio check out the project when adding the new item.
- Immediately check in the project and new item as it was added. Generally a build test isn't necessary on new items because they are void of non-compiling code. (Continuous Integration can help ensure this even if your local build doesn't work due to other changes you are making.)
- Proceed to edit the new item which will need to be checked back out.

By using this procedure the project file gets checked in and the new (empty) item is added to source control resulting in a successful build. Now when another developer needs to modify the project or add an item to it, they'll get the updated project as well as the empty item which will compile. They can then keep working without compile problems.

Here are a few other things I've found to help:
- If you don't already, try using Visual Studio's Pending Checkins toolbox window so you can easily see what is checked out to you within the solution. It's much easier than searching thru the solution explorer or using VSS explorer. Using this reduces the likelihood of forgetting to check in a file.
- Don't let Visual Studio automatically check out files. You'll be much more likely to remember that you need to check files in if you were forced to acknowledge their checkout.

I realize that another solution to this problem is to use the modify-merge-commit method. However, the fact is that many development teams use Visual Source Safe, and VSS doesn't have the best merge tools so the exclusive checkout method is preferred for it's stability.

Even working on aggressive projects with many developers working in the same projects, I've found that 2 developers are rarely working in the same exact file(s). Using this technique to maintain the project integrity goes a long way to reducing interference between developers.