Will Code For Food;

We removed integration several years ago. We found that it actually causes more trouble then it solves, especially if you start getting into complex scenarios with branching etc. FOr simple scnarios it can be handy, but the pain far outweighs the benefit.

No way. The way it's implemented leaves a lot to be desired when working in a realistic setting.

Simplest use case: I code on two projects, one of which uses Perforce and the other uses SourceSafe. Since the SCC provider is a machine-wide setting, I can't use either one - whenever I try to open the "wrong" kind of project, VS gets all spazzy and throws a bunch of annoying errors.

There are others but this alone was reason for me to mandate no SCC integration on my projects.

My only experience with SCC integration is with the ust of Visual Source Safe (Microsoft's default SCC product) - so I haven't tried other tools, and cannot comment on SCC integration generically in Visual Studio.

I find that the Source Safe integration in Visual Studio makes a lot of assumptions that I don't always agree with.

A couple of problems I've had with it that stand out in my mind:

Occasionally checks in files that should not necessarily be source-controlled

Resets working directories on source safe projects without warning (and can sometimes cause confusion this way)

I always end up doing all my own source control outside of visual studio, but as I work in a team environment, most of the projects are still bound when I open them (which causes countless other synchronization problems if my environment is set up slightly differently than my co-workers)

Another thing that turns me off is the number of "scc" files that have to exist on my disk.

Pro: SCC integration takes care of adding only those those files that are actually required.
Con: Rename is not possible in VS.Net 2003

I use VSS explorer only for getting whole trees, sharing [and branching], renaming.

Marc