Is My Team Facing "The Problem"?
In today's global and diversified development environment, it is common for development teams to require remote and cross-platform access to their source code repository. Software products are routinely built by distributed teams. Whether developers on these teams are working from home, on a business trip, as an outside contractor, or as part of a global development team, they all need to access the same code base.

MICROSOFT VISUAL SOURCESAFE
Microsoft Visual SourceSafe (VSS) is a popular source control package, and is ideal for sharing code across a local area network. It provides essential source control functions and has excellent integration with Microsoft development solutions. Although widely used and based on Microsoft technology, SourceSafe has limitations with security remote access performance, data corruption, cross platform support and non-MSSCCI IDE integration.

POOR SECURITY
Source code is one of the most valuable assets for an organization. As development moves outside the LAN, security becomes a top priority since the code repository needs to be protected from accidents as well as malevolent attacks.

In SourceSafe, you need to grant the READ & WRITE permission of the WHOLE VSS database folder recursively to the user who needs access to the VSS database, even though the user may only need to read one single file. Doing this may be OK behind the firewall. But exposing your source code database to the public Internet is a totally different story and brings great risk for your source code.

Also, exposing the VSS database folder to the Internet means you need to open up the fire sharing port in your firewall, which could mean the file sharing port of your entire LAN is open up to the Internet if you do not have another layer of security measurement.

In short, sharing VSS database over Internet exposes too much of your valuable data to the outside, which may potentially cause the data to be stolen or damaged. These damages could not only impact your VSS database, but possibly your entire LAN.

SLOW REMOTE ACCESS PERFORMANCE
Over a slow Internet connection, VSS becomes almost unusable. SourceSafe could take more than 10 minutes to open a project or several minutes to check in a single file when it is used remotely over Internet.

However, when a company has remote developers, they need to be using a version control tool that has fast remote access so that they can access the files quickly and efficiently. A developer's time is expensive, and shouldn't be wasted checking code in and out from the repository over a slow connection.

VSS DATABASE CORRUPTION WHEN ACCESSED REMOTELY
Whether you are accessing your VSS database locally or remotely, VSS Explorer treats the VSS database as files on a disk driver. Due to the internal structure of SourceSafe, one operation involves reading and writing a bunch of files. For example, to check in one file involves reading more than 10 files and writing several files. Since the file operation is not transactional, if something happens when the VSS Explorer is writing a file, it is very likely, that the VSS database will corrupt. It is also possible when operating on a remote VSS database because the operation takes a much longer time. During that lengthy process, one network glitch can interrupt the writing process and leave your VSS database half cocked. This is why Microsoft recommends analyzing and repairing the database on a weekly basis.

LACK OF CROSS-PLATFORM SUPPORT
Additionally, VSS only supports the Windows platform. If your team uses development platforms in addition to Windows, they may need to take the extra steps to check in and check out files from Windows and copy them back and forth to other operating system through SMB.

ONLY SUPPORTS MSSCCI IDE INTEGRATION
VSS only supports MSSCCI compatible IDE integrations, such as Visual Studio. If you are using any non MSSCCI compatible IDEs, like Eclipse, you do not have the convenience of operating the source control file without leaving the IDE.

Why the Problems?
The main cause of the problems is the fundamental design philosophy of SourceSafe: a version control tool for small teams working in LAN. The cross-platform and ITE compatibility issues are due to the overall Microsoft product policy of promoting Microsoft Windows system and other products.

The technical reason for the slow remote access performance and security issues is that VSS is a file based system. Without an application/server tier, the SourceSafe Explorer needs to go through the files to get the data by itself, which involves lots of file reading and writing. With client/server or multi-tier applications, the client only needs to send the request to the server and get the result back. No more and no less. Since the Windows file system is not transactional, if the writing operation is interrupted, it is very likely that the data is corrupted. (Even though Windows Vista ships with transactional file system, SourceSafe does not take advantage of it.) Also, since file sharing is an operating system level feature, exposing the SourceSafe database to the Internet could expose the shared file system to the public.

So, What Are the Options?
As distributed development becomes more and more pervasive, Microsoft Visual SourceSafe cannot meet a remote development team's need for performance, security, and multi-platform development. The alternatives include:
  •   increasing the network speed
  •   using a VPN
  •   using a third-party VSS remote access add-on tool

INCREASE NETWORK SPEED
One option is to have a faster network. By increasing the network speed, VSS becomes more functional over the Internet. However, many developers are already accessing the Internet at maximum remote speed and their remote access to VSS is still too slow. Besides, this option does not fix the security and limited platform support inherited with VSS. Also, increasing network speed can be very costly to set up and, in many locations, there is no such infrastructure available to carry out this option.