Visual Source Safe thru VPN not working

[lozina]

I am working at home alot now for my old job and I connect into their network via VPN. I can go into stuff like TOAD and run all kinds of SQL, I can run the web application I am helping with fine, I can transfer files fine- but source safe is having a problem.

I can actually get latest version ok but as soon as I try checking anything out of source safe i get this Windows Delayed Write Error and soruce safe stalls.

I am using Windows XP sP2 and connecting using Lunksys VPN client (QuickVPN)

any ideas?

 

[spacelord]

No ideas, but Source Safe runs like a pig over VPN connections.
I'd do some Googling about the Delayed Write Error and Source Safe.

 

[Jaxidian]

What version of SourceSafe and what SPs do you have installed for it?

 

[lozina]

VSS 6.0d Build 31222
I didn't have the latest SPs before though and I just installed them but getting same issue

 

[lozina]

perhaps someone in the morning crowd might know about this ?

 

[Jaxidian]

Originally posted by: lozina
VSS 6.0d Build 31222
I didn't have the latest SPs before though and I just installed them but getting same issue

That's what I was going for - making sure you had 6.0d if it was that version.

Sorry

 

[lozina]

Originally posted by: Jaxidian

That's what I was going for - making sure you had 6.0d if it was that version.

Sorry

I notice there is a Visual Studio 2005 , you know anything about that one?

Maybe I can convince my boss to buy it for me if I am sure it will solve this problem

 

[jcgrcm]

Hmm, you have me worried, I will probably have to run SS over a VPN in a few months.

One thing I have noticed is the Anti-virus software (Norton in this case) can have a really huge impact on the speed of SS. Even with local servers it is noticably slower (order of magnatude) when Norton scanning the drive where the SS database is. Try ensuring that any anti-virus software is not scanning the drive where you have the database.

Also don't delete any of the vssver.scc files that sourcesafe leaves out there, I believe those are checksums of the local files and are used to improve network access.

 

[clamum]

I also connect to it through VPN and holy man is the fvcking thing slow. I'm gonna check Symantec's settings as jcgrcm suggested...

 

[lozina]

Yeah I use AVG antivirus so I tried just closing it down and that didn't provide any difference.

Also I shut down my Sygate software firewall with no difference.

Tomorrow I am going to try SourceSafe 2005 - someone at work is going to let me 'borrow' it to test if it solves the problem.

 

[lozina]

Well, tried Source Safe 2005, and same exact problem. I can get latest version, but the moment I try to Check in/Check out - Delayed Write Error and the operation fails.

Ugh...

 

[Markbnj]

For what it's worth, and I don't know that this will be any help, Visual Source Safe is not... um... safe over a VPN, or any other distributed team environment as far as I am concerned. The biggest problem with VSS in terms of robustness is that it relies on shares to map the repositories. I would not use it in any situation where the developers weren't all sitting next to the server (i.e. connected to it via 100/1000 ethernet).

There are two better choices, imo. First, MS is phasing VSS out as we speak in favor of Visual Studio Team System. Team System Server includes a completely new source control system that is _far_ more robust in all situations, especially in distributed team development. Team System is, of course, not free. It can cost as much as $10k per server and a grand or so per developer seat. Less on volume licensing programs.

A robust and free alternative is CVSNT (not CVS, which has its own fragility issues). CVSNT is a more robust update to CVS. The server components are free for the download, along with the command line tools for file management. If you want Visual Studio 2005 integration through SCCI then you can purchase CVS Suite from March Hare for $150 (approx.) per seat. This includes TortoisCVS (which is the Explorer integration, and provides the client-side engine for SCCI integration with VS), WinCVS, and tested builds of the server (CVS Suite Server).

We are currently using CVSNT in a distributed team environment, largely because I couldn't get the client to pony up for Team System. So far we've been happy with CVSNT.

 

[lozina]

So, in other words, there really is no solution to this problem? Damn, we all know VSS sucks but it would be such a pain to migrate to a new system.

 

[clamum]

I was going to update this thread but I see you already tried shutting off your AV software. I shut off network drive scanning on mine and now VSS isn't as slow as molasses in January.

Sorry about your problem though, good luck.

 

[Markbnj]

>> Damn, we all know VSS sucks but it would be such a pain to migrate to a new system.

Heh, sorry. Advice that doesn't help is worse than none at all.

Here's a post from a guy that had the same problem, and found that setting the NIC on the server to 100 mbps full duplex (from autonegotiate) solved the delayed write problem.

http://blog.roblevine.co.uk/?p=4

Might be worth a try. There are a couple of MS KB articles referenced in that post as well, that might be useful if you're getting any event log info.

 

[jcgrcm]

Have you tried archiving/splitting the project?

I believe the reason why SS runs like crap is the way that it handles the file delta and the admin data. If you look in the data subdirectory for the database, there are a bunch of directories from a-z, every time you check in a file it hashes a filename (I think maybe 2, one for the history data and another for the actual file delta) and save it out there. Since all changes are distributed across those 26 directories, you can quickly get thousands and even tens of thousands of files in each single directory. It is having to read each huge directory that really kills it, and the fact that it has to chain though multiple files to get the versioning for even a single file.

You might want to try archiving off older revisions of the database, we had to do that a long time ago when we had a problem with just a slow server and too many files. I don't remember the exact details of the archiving we used (that was 6-7 years ago), you have to be careful since there are settings to create the archive but not clean up the delta files. I do remember it literally took 3 or 4 days to run (brutal).

Nowadays we just create a new database for every major product/project. Keeps things simple/quick.