speed up SOS on LAN or perils of switching SCC's repeatedly

[Mark B]

When I am on the road, SOS works great - I get access to VSS files through our VPN much faster than using VSS as the SCC.

But when I'm working in the office, connected to the LAN, VSS performs much faster than SOS. I would expect VSS to be faster than SOS because SOS has to go through the VSS automation layer, but the difference is fairly dramatic (5-10 fold) - getting file lists seems to be the real culprit (even in the SOS client). I am working on a large .NET solution (5 projects, perhaps 150 modules all told), and just opening the solution (on the LAN) takes close to a minute, while VSS does it in less than 10 seconds.

Is there any way to speed up SOS on the LAN? I have already configured antivirus software on the server to ignore files in the VSS DATA and SOS temp folder hierarchies.

Barring that, what is the down side to using VSS when on the LAN and SOS when out of the office? I hear that there are "problems" switching SCC back and forth, but are there any details about how to do this safely (e.g., "don't switch while any files are checked out" or some such) or at least details about what the problems are?

Thanks

[corey]

There's two main problems with switching back and forth between SOS and VSS on the same machine.

First, SOS tries to keep track of local file status, and using VSS to get and check in files behind SOS's back can cause problems, leading to files becoming "Renegade" or "Unknown".

Second, Visual Studio persists source control binding information in local files stored in the project's directories, such as the MSSCCPRJ.SCC file. If you switch back and forth between source control providers, you'll probably need to unbind and rebind your project or else Visual Studio will probably get confused.

Basically, its possible to switch back and forth, but its time consuming and error prone so we usually don't recommend it to users.

What version of SOS are you using? We made a few changes in SOS 4.0.2 which improves file list retrieval speed within Visual Studio. That may help a bit with solution load times, etc.