Compare before every check-in

If you don't compare every file before you check-in, you are more likely to check something in that was only needed for testing the change. (or something that was you trying to figure out how to solve the problem, and is now dead code) Additionally, If you do compare every file, you get to see what a diff program (and another human would see) when trying to compare the before to after. You can then optimize the code so that a diff is far more readable (if only for that check-in, then check-in again if you desire a specific order for how the file should read). Version Control Systems that have easy staging of parts of a file instead of all changes can make this even easier. Since, you may want to keep your local changes for testing, without checking them in for more testing or more feature additions. (or even permanent testing additions for your local workspace)

Using a Git layer on top of TFS

Not having git bugs me. Working with any other source control system takes away some of my power.

With a git layer over whatever other source control system is required for the team:

• I can check-in or revert individual lines of code in a file. 
• I can create a branch for local modifications that should never be checked into the team source control.
• I can create mini-commits that don't have to be logged as individual commits in the team source (for teams that prefer one large change-set)
• I can create my own personal historical record of change save-points and notes/comments
• I can select which lines of a file should go into a check-in without shelving the entire change.

How to:

Create a junction or hardlink to the folder that contains your code. This junction must not be in the tree that your tfs workspace mapping sees. If it is, Visual Studio will then, forcefully and persistently, use git as your source control and refuse to talk to TFS about your changes.

So I have all my code under c:\development\foo

1.  I change working directory to c:\projects\bar and mklink /h /j foobar c:\development\foo
2. git init
3. Always point visual studio at the legacy folder c:\development\foo.
4. Always point your git tool(s) at c:\projects\bar
5. profit!

Source Safe potentially unsound

This article brings some concerns to the possible switching to SourceSafe to be consistent with our partner team(s):

http://www.codinghorror.com/blog/archives/000660.html

                -“There's simply no reason to use SourceSafe when there are so many inexpensive (and even free) alternatives that are vastly superior”

-“SourceSafe was a perfectly adequate source control system in the late 90's. Unfortunately, SourceSafe was never updated architecturally to reflect modern source control practices. Even the latest version, SourceSafe 2005, absolutely reeks of 1999”

-“SourceSafe gives you the illusion of safety and control, while exposing your project to risk. “

-“SourceSafe teaches developers bad habits: avoid branching, exclusive locks, easy permanent deletions. “

with links to major issues and risks using SourceSafe:

• Visual SourceSafe: Microsoft's Source Destruction System
• Visual SourceSafe Version Control: Unsafe at any Speed?

Conclusion:

 -“Visual SourceSafe was most Microsoft developers' first introduction to any kind of source control at all. That's great. But holding on to SourceSafe's archaic source control conventions is doing more damage than good these days. Make the switch to Team System, Subversion, or any other modern source control system of your choice. “

Team System is also from Microsoft as a version control system for teams of programmers.  My current estimation is that it is probably over the top in cost and functionality for our needs.