I have been using SourceSafe (6.0D) over a 1.6 MB DSL line for several months with great success. Recently, I brought on two more developers for my project, and both of them had just horrific results.
From within VB.NET I could do a “get latest copy recursive” of our source files in less than a minute. (To make all tests equal, we did one “get latest copy recursive” to be sure we had the most recent files, and then did another for testing the timing.) For both of my cohorts, it took over five minutes and this was for the SECOND time through when there should have been no differences to resolve! We all used the same ISP, we all used the same DSL provider, we all connected via a Windows 2003 SBS Server VPN to my office domain, we all had the same version of VB.Net and SourceSafe. This was just too strange.
Determined to get to the bottom of this, we ran several tests. I watched a “Routing and Remote Access” / “Remote Access Clients” / Status dialog box on the VPN server to get an idea of how much data was traversing the VPN as we did this checkout. That was VERY enlightening. My “get latest copy recursive” transferred about 70 KB, and both of my cohorts had transfers of over 5 MB. That’s right! 5 MEGABYTES!!!
Surely we were on to something, but what? My first thought was maybe the COMPARE method we were using was different. Long ago, when I set my access to SourceSafe up, I had remembered reading an article about SourceSafe over RAS with an admonition NOT to use the “by contents” method. The Checksum method was preferred. Armed with that recollection, I called my cohorts, eager to give them the “fix.” Ha! They both had that same setting that I did! Damn! What could this be? Read on; we DID find out.
Today, we decided to really get to the bottom of this. We installed a copy of that venerable old detective tool, FILEMON, and carefully did a trace of all the file IOs on my machine while doing a “get latest copy recursive” and a trace on one of the other machines. Viewing that trace, it became obvious that SourceSafe was, indeed, transferring a LOT less info to my machine. We’d see that the three machines did pretty much the same amount of IO up to the point where the “CRCS.DAT” file was first accessed. (That file stores the CRC signatures for the objects stored in the SourceSafe “database.”) After that, my machine would have a few more lines of IO in FileMon. The other two slow machines would have TONS of lines of IO. This same thing was repeated as each local file’s CRC was checked against the one in the CRCS.DAT file. I’d have a few lines; they’d have HUNDREDS. It was obvious their machines thought the CRCs were different on the local versus SourceSafe copy and they were pulling the entire project over the DSL line every single time.
Now we were really zeroing in on the problem. What could cause the CRC check to fail like this? I also remembered seeing many reports about Norton Antivirus causing major slowdowns with SourceSafe. I asked my two cohorts what anti-virus they used. They both replied NAV! (I use Panda.) I asked them both to disable Norton AV and the results were astounding. Their 5 MB transfers dropped to 70K, just like mine!
We Turned NAV back on and the transfer climbed back to 5 MB. Now remember, after the initial “get latest copy recursive,” all of the machines had IDENTICAL files in their local directories. We tried this several more times. With NAV, the whole project was pulled from the server – without it, nothing was being pulled.
The communal wisdom on NAV being a problem with SourceSafe in the past revolved around the time it was taking for NAV to scan the files. I have found that this is not the situation at all. The problem is that NAV is somehow screwing up the CRC comparison process that SourceSafe is using. That is a bit alarming as NAV should in no way alter the results of reading and writing data from the hard drive, but it obviously does.
So, for those of you out there who want to use SourceSafe over a DSL connection, I can tell you that it works great and there are no real performance issues at all, unless you are also using Norton Antivirus. You’ll need to turn it off or switch to an anti-virus solution that does not interfere with the low-level reading of data from your hard drive. [Gary Shell]