The quotes and statistics mentioned in this note come from various prospects and customers of Perforce who have direct experience using VSS.

Performance

• Perforce is faster than VSS for nearly every operation. VSS's labeling is faster than Perforce, but for every other command Perforce is faster. VSS is particularly slow at getting older versions and adding new files.
• Perforce is known for its speed in any configuration of platforms, not just a Windows environment. The client/server communicate via TCP/IP.

VSS becomes very slow in a cross-platform environment because it is necessary to configure the product for a very slow file-semaphore locking scheme.

A quote from a prospect about the speed of VSS with its UNIX client:

"VSS/UNIX is about 10 times slower than P4 (real time). P4 is also a lot gentler on the CPU usage, 2-4% on an UltraSparc."
• Perforce scales well as your system grows. Performance is not greatly related to database size.

Performance of a VSS database becomes truly awful as your VSS database grows. If you use branching, it grows far larger than you'd expect with VSS's unnecessarily-replicating branching scheme.

• Perforce is the best system available for remote access. Perforce can run well even over the slowest modem lines.

VSS admits that remote access is slow, although they believe it's faster in VSS 6.0 under Windows's RAS services. Their suggestion: "instead of running connected is to check files out while connected, drop the connection, and submit next time you connect."

Here is a quote from a customer:

"The main problem I had with source safe 4.0 is that it is virtually unusable over a slow connection"

Reliability

• Perforce is a true Client/Server system running over socket-level TCP/IP. This is inherently more reliable than a fileserver-based system like VSS. VSS is usually MSNetwork-hosted or, if the environment is UNIX/Windows, NFS-hosted.
• Perforce uses a standard RCS depot format, which makes files visible and accessible. This makes troubleshooting and data exportability a simpler issue.

Your files are not visible within a VSS database. The "Analyze" utility is not as thorough as one might wish, making debugging problems that much more difficult.

• VSS has earned its nickname of Source-Unsafe. Corrupt databases are not unusual. In fact, the Visual SourceSafe Best Practices writeup from Microsoft is devoted to the following topic:

  "Summary: Outlines recommended practices to help prevent data corruption in Microsoft Visual SourceSafe."

  This might sound like it's taken out of context, but the entire paper is devoted to that one topic. By contrast, the Perforce counterpart is devoted to codeline layout for managing your code.

  These quotes are from Perforce prospects:

• "We're really anxious to drop VSS, since corrupted databases aren't anyone's idea of a useful development tool."
• "Database became corrupted several times and sometimes the "Analyze" utility didn't show any problems"
• "File locks were frequently left behind and had to be manually removed."
• "Large binary files OFTEN had to have their version history cleared with 3.1"

Useability

• Ease of use is VSS's strong suit, at least on the MS-Window's side. UNIX users or command line users would not find it so intuitive, however.

Perforce now supplies a GUI for NT with its 97.2 release (May 1997).

• Perforce has a very strong branching model, "inter-file branching".

VSS's branching involves sharing a folder, then selectively branching off selected or all files within that path; non-intuitive. It also eats disk space, as any space-saving diff storage doesn't occur between branched versions of the files.

For complicated development projects, VSS's branching is inadequate. The branching isn't flexible enough for multiple trees of development. This isn't the market VSS is selling to, as evidenced with this comment from their web pages: "For the needs of most corporations, creating and maintaining multiple branches is overkill".

• The Perforce server contains a database engine supplying locking and atomic change transactions. Either an entire set of files will be checked in at once, or not at all, for the operations add, delete, and edit.

VSS does not allow for including adds, deletes, and edits in a single change.

• VSS might be the SCM of choice for the trivial case of a couple NT developers managing a handful of files.

Perforce is the obvious choice for a serious development effort.

Here are some quotes from prospects:

"Everyone also knows that VSS is not industrial strength. (maybe barely so, but with some serious architectural flaws)."
"(VSS) is used currently. Great for entry level engineers with a very simple UI. However, the version control itself is very bad. Branching doesn't work. Labeling is very fast but even more error-prone. Certainly not the ideal system."
• A change review facility is not part of VSS.

GUI

• Prior to the Perforce 97.2 release, which was the first Perforce release to provide a GUI interface for Windows customers, some customers bought VSS to get its GUI. (The VSS GUI supported 16-bit clients, a.k.a. Windows 3.1.)

  Since then, the Perforce GUI has become more robust, while VSS 5.0 discarded the distinguishing feature it had: 16-bit client support. So there's no compelling reason to purchase VSS - certainly not just for the GUI.

• Since Perforce supplies all clients for all platforms at no extra charge, there is no need to go to a different vendor to purchase Perforce client software.

VSS does not supply the GUI for its Mac and Unix clients. The VSS GUI for Unix is available from MainSoft. From comments customers have sent us, the GUI on Unix is buggy and slow. These comments are direct from a prospect:

"We have several windows programmers who strongly insisted on using VSS, so we decided to try it. The results are dismal. The UNIX version is buggy and slow."
Metroworks Codewarrior supplies the GUI on Macintosh.

Scripting

Perforce is easily scriptable, and the command-line interface is usually what's used to implement build systems. Most customers write overnight (and production) build scripts in their favorite scripting language, which is their choice - not Perforce's! Some customers use perl, others use Python, but it's not necessary to use such a powerful scripting language; other customers use the Unix Bourne shell or Korn shell, and others use the Windows/NT command-interpreter to write .cmd/.bat scripts.

To be fair, VSS 5.0 allows for OLE applications to run VSS via remote control, to create a build system; VSS 6.0 even lets Visual Basic programmers do their magic.

Only, do you really want to hire a wizard to program your build system when you're looking for an engineering solution? OLE and VB aren't known for being simple to code or maintain, and they're clearly Windows-specific tools.

In fact, it's easy to imagine an unprivileged Perforce user writing a small script to "add two files, delete a third, and submit the change". The effort to do code this into an OLE or VB application violates keeping simple tasks simple - one of the Perforce goals.

Feature by Feature

The list of things that VSS supports is impressive: OLE automation, shared/pinned files, a slick GUI. Unfortunately, the underlying software isn't up to supporting basic needs - so these slick features aren't as compelling as they might be.

For example, OLE automation is terrific (if you're an OLE developer). Unfortunately, the power of OLE is hobbled by its complexity.

VSS supports "shared files", in which a file appears in two locations. It also supports "shared but not editable" in recent versions, which is called "pinning the file". That "pinned file" model is what a Perforce branch does - files in a branch don't move out from underneath you unless you push fresh content to the branch.

The GUI for VSS is nice, no doubt about it. However, a few things remain missing: enforcement of checkin comments, for example, or the difficulty in switching between two workspaces when you've used multiple workspaces to manage your work.

There are things that you can buy for VSS as add-ons, that are part of Perforce: support for multiple platforms, Y2K support (new to VSS 6.0!). Moreover, there are separate mechanisms for basic reporting in VSS - whereas Perforce is useable from the command-line for basic "data mining".

It's very telling to look at the VSS 6.0 list of "What's New in Visual SourceSafe 6.0?": most of the "new features" are attempts to match basic functionality that Perforce has had for several releases.

VSS 6.0 "feature"	Comments
Enhanced File Get and Check-out	remote access (RAS) is substantially faster, but the Perforce model (in which you can do 'incremental' updates to your workspace) means you transfer less data and complete the operations more quickly.
Year 2000 Date Formats	Available in Perforce since 1997
New Web Capabilities	You can publish to a web server - the Perforce WebKeeperTM plug-in provides this functionality.
Label Promotion	This allows you to add files to an existing label (or remove them from the label). This is something Perforce always had.
Expanded OLE Automation	Perforce supports most common scripting languages, e.g. perl/python/shell.
HTML Help	Perforce's manual is on the web in HTML, and the GUI help is, well, on-line.
Compare Differences in Multiple Projects	This has been part of Perforce since the beginning.
Multiple Databases	Perforce has had support for multiple repositories, managed by the same or by separate servers, since 1997.
Filter History Information	It's suprising to find out that a SCM out there requires you to label files/projects before viewing their history - Perforce believes that this is a standard thing, and has been there since the beginning.
Check External Hyperlinks	Okay, having external hyperlinks might be nice.
Edit/View Dialog	In Perforce, you've been able to set the 'helper applications' for editing/viewing files, since 1997.

Support and Upgrades

The first year of Perforce technical support is included with the cost of the software; subsequent years of support are included with the cost of continuing maintenance releases ($120/year/user.)

VSS support is expensive: the first two incidents are free, subsequent ones are billed at $95/incident. (You can purchase a block for slightly less.)

In addition, upgrades for VSS aren't cheap: $279.00/machine.

This page last updated on 15 June 1999.