The source control integration in Visual Studio is pretty and also braindead. It usually takes days to weeks to get a simple web project with a few dependencies able to be worked on by multiple people. These are problems I've experienced with Visual Studio 2005 and Team Foundation Server:
By default, mappings to source control for a project are stored in three separate places, with no automatic way to synchronize them all, and no way to view or modify them directly through the GUI
In the solution file
In the source control bindings file in every folder
In project files
Undocumented "heuristics" are used to second guess whether a project is actually under source control, and get other useful information. So, frequently, using source control means guessing how to trigger the correct action by setting up your entire solution the way Microsoft considers the most "pretty".
By default, solution files store some absolute paths
In new-style web sites, it's not possible within VS to reference a different version of a library than the one in the GAC. This is trouble since assemblies must be in the GAC for those controls to be used from the Toolbox!
Visual Studio will sometimes automatically check out source-controlled project files and make no changes in order to fix the user's local settings, or check files out to "fix" settings that conflict with another user's machine. Inattentive developers will check out and lock important files and then go on working, since this is the default behavior of Visual Studio.
Web sites automatically converted from .NET 2003 will trigger most of these problems either directly, or when trying the most obvious things to fix the resulting breakage.