Recently, I did the test. Now I am posting the result here with the hope that it can save your time evaluating different SourceSafe remote access tools. I mainly focus on the features and remote-access performance comparison.

Below is the result:

Feature Comparison

Features		SourceOffSite
Performance Features
Data compression
Client/Server architecture
Cache Server
Delta Transfer
Multithread file transfer
Security Features
Client/Server Architecture
Blowfish encryption
128 SSL
Password policy
Independent VSS database access control
IDE Integration
Visual Studio 6/2003/2005/2008
SQL Server 2005
Eclipse Plug-in
Dreamweaver
Cross Platform
Windows
Linux
Mac
Solaris
AIX
SCO
Any Java compatible platform

Performance Test

Result: (Unit: second)

Test Environment:
There are 3 machines used in the test:

Server : CPU Intel P4 2.66G, 256M RAM, Win 2003 Std sp1; SourceAnywhere for VSS Server 5.3.1; SourceOffSite Server 4.2

Client: CPU Intel P4 3.0G, 512M RAM, 160GB 5400RPM HD, Win XP sp2; SourceAnywhere for VSS Server 5.3.1; SourceOffSite Client 4.2

Cache server: CPU Intel Celeron 2.66G, 512M RAM, 160GB 5400RPM HD, Win2003 Std SP1; SourceAnywhere for VSS Cache Server 5.3.1

Broadband connection is used between the client and server machine.

The cache server and client are on the same LAN, which connects to the server through office ADSL.

Test Software:

SourceAnywhere for VSS 5.4, SourceAnywhere for VSS 5.4 Cache Server 5.4, SourceAnywhere for VSS Client 5.4.

SourceOffSite Server 4.2, SourceOffSite Client 4.2.

Test Data:

1. A project with 1,500 files; Total size is 17.1 MB.
2. 1,000 changed files (used for check-in).
3. Server and Client machines are restarted before each test.

I attached the test data I used here. You can download it and do the test in your own environment if you like.

Test method:

Every operation is carried out 5 times. The highest and lowest results are eliminated. The average value is calculated.

You can read more at this page:
http://silverlight.net/getstarted/silverlight3/default.aspx

In the coming 2 weeks, our team will continue to work on the cross-platform client to further improve the product quality. 2 weeks later, our testing team will start to do release testing for the client and our coding team will start to work on the Visual Studio IDE integration client.

The original post is:

I’m having a problem with a network application I’m coding. I have this connection between a client and a server that only works when I start my application with “Start with debugging” and never with “Start without debugging”, both in Debug and Release configuration.

So my question is : what’s the differences with “Start with debugging” and “Start without debugging” that could possibly change the behaviour of a program? Because I don’t have a clue as of where to search for the problem… If it can help, my program is multi-threaded.

I also had the same question several years ago.

This issue is caused by the different variable initialization behavior of differnt run modes.

In the “Start with debugging” mode, the un-initialized variables are set to the default values. But in the “Start without debugging”, the variables are left random.

For example, you have:
int iHowMany;

In the “Start with debugging” mode, iHowMany is initialized to 0. But in the “Start without debugging” mode, the value of iHowMany is random.

It is easy to find all the un-initialized variables. The VC compiler generates a warning for using an un-initialized variable. Just go through the compiler warning list, find them and initialize them.