<html><body>
<center>
<h2>
Comparison with Visual Sourcesafe</h2></center>
<center>
<h4>
<i>Originally compared VSS 4.0 to Perforce,<br>
updated to include VSS 6.0 comments.</i></h4></center>
This note compares Perforce and <i><a href="http://msdn.microsoft.com/ssafe/">Visual Sourcesafe</a> (VSS)</i>,
a source management system sold by Microsoft.
<p>The quotes and statistics mentioned in this note come from various prospects
and customers of Perforce who have direct experience using <i>VSS</i>.
<h3>
Performance</h3>
<ul>
<li>
Perforce is faster than <i>VSS</i> for nearly every operation. <i>VSS</i>'s
labeling is faster than Perforce, but for every other command Perforce
is faster. <i>VSS</i> is particularly slow at getting older versions
and adding new files.</li>
<li>
Perforce is known for its speed in any configuration of platforms, not
just a Windows environment. The client/server communicate via TCP/IP.</li>
<p><i>VSS</i> becomes very slow in a cross-platform environment
because it is necessary to configure the product for a very slow file-semaphore
locking scheme.
<p>A quote from a prospect about the speed of <i>VSS</i> with its
UNIX client:
<ul><i>"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."</i></ul>
<li>
Perforce scales well as your system grows. Performance is not greatly related
to database size.</li>
<p>Performance of a <i>VSS</i> database becomes truly awful
as your <i>VSS</i> database grows. If you use branching, it grows
far larger than you'd expect with <i>VSS</i>'s unnecessarily-replicating
branching scheme.
<li>
Perforce is the best system available for remote access. Perforce can run
well even over the slowest modem lines.</li>
<p><i>VSS</i> admits that remote access is slow, although they
believe it's faster in <i>VSS 6.0</i> 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."
<p>Here is a quote from a customer:
<ul><i>"The main problem I had with source safe 4.0 is that it is virtually
unusable over a slow connection"</i></ul>
</ul>
<h3>
Reliability</h3>
<ul>
<li>
Perforce is a true Client/Server system running over socket-level TCP/IP.
This is inherently more reliable than a fileserver-based system like <i>VSS</i>.
<i>VSS</i> is usually MSNetwork-hosted or, if the environment is
UNIX/Windows, NFS-hosted.</li>
<li>
Perforce uses a standard RCS depot format, which makes files visible and
accessible. This makes troubleshooting and data exportability a simpler
issue.</li>
<p>Your files are not visible within a <i>VSS</i> database.
The "Analyze" utility is not as thorough as one might wish, making debugging
problems that much more difficult.
<li>
<i>VSS</i> has earned its nickname of Source-Unsafe. Corrupt databases
are not unusual. In fact, the <a href="http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/techart/vssbest.htm">Visual SourceSafe Best Practices</a>
writeup from Microsoft is devoted to the following topic:
<blockquote>
"Summary: Outlines recommended practices to
help prevent data corruption in Microsoft Visual
SourceSafe."
</blockquote>
This might sound like it's taken out of context, but the entire paper
is devoted to that one topic.
By contrast, the Perforce <a href="http://www.perforce.com/perforce/bestpractices.html">counterpart</a> is devoted to codeline layout for managing your
code.
<p>
These quotes are from Perforce prospects:</li>
<ul>
<li>
<i>"We're really anxious to drop VSS, since corrupted databases
aren't anyone's idea of a useful development tool."</i></li>
<li>
<i>"Database became corrupted several times and sometimes the "Analyze"
utility didn't show any problems"</i></li>
<li>
<i>"File locks were frequently left behind and had to be manually removed."</i></li>
<li>
<i>"Large binary files OFTEN had to have their version history cleared
with 3.1"</i></li>
</ul>
</ul>
<h3>
Useability</h3>
<ul>
<li>
Ease of use is <i>VSS</i>'s strong suit, at least on the MS-Window's
side. UNIX users or command line users would not find it so intuitive,
however.</li>
<p>Perforce now supplies a GUI for NT with its 97.2 release (May 1997).
<li>
Perforce has a very strong branching model, "inter-file branching".</li>
<p><i>VSS</i>'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.
<p>For complicated development projects, <i>VSS</i>'s branching
is inadequate. The branching isn't flexible enough for multiple trees of
development. This isn't the market <i>VSS</i> 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".
<li>
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.</li>
<p><i>VSS</i> does not allow for including adds, deletes, and
edits in a single change.
<li>
<i>VSS</i> might be the SCM of choice for the trivial case of a
couple NT developers managing a handful of files.</li>
<p>Perforce is the obvious choice for a serious development effort.
<p>Here are some quotes from prospects:
<ul><i>"Everyone also knows that VSS is not industrial strength. (maybe
barely so, but with some serious architectural flaws)."</i></ul>
<ul><i>"(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."</i></ul>
<li>
A change review facility is not part of <i>VSS</i>.</li>
</ul>
<h3>
GUI</h3>
<ul>
<li>
Prior to the Perforce 97.2 release, which was the first Perforce
release to provide a GUI interface for Windows customers,
some customers bought <i>VSS</i> to get its GUI. (The <i>VSS</i>
GUI supported 16-bit clients, a.k.a. Windows 3.1.)
<p>
Since then, the Perforce GUI has become more robust, while
<i>VSS 5.0</i> discarded the distinguishing feature it had: 16-bit
client support.
So there's no compelling reason to purchase <i>VSS</i> - certainly
not just for the GUI.
<li>
Since Perforce supplies all clients for all platforms <u>at no extra charge</u>,
there is no need to go
to a different vendor to purchase Perforce client software.</li>
<p><i>VSS</i> does not supply the GUI for its Mac and Unix clients.
The <i>VSS</i> 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:
<ul><i>"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."</i></ul>
Metroworks Codewarrior supplies the GUI on Macintosh.</ul>
<h3>Scripting</h3>
<ul>
<p>
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 <i>perl</i>, others use <i>Python</i>,
but it's not necessary to use such a powerful scripting language;
other customers use the Unix <i>Bourne shell</i> or <i>Korn shell</i>,
and others use the Windows/NT command-interpreter to write <i>.cmd/.bat</i>
scripts.
<p>
To be fair, <i>VSS 5.0</i> allows for OLE applications to run <i>VSS</i>
via remote control, to create a build system; <i>VSS 6.0</i> even lets
<i>Visual Basic</i> programmers do their magic.
<p>
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.
<p>
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 <u>keeping simple tasks simple</u> - one of the Perforce goals.
<p>
</ul>
<h3>Feature by Feature</h3>
<ul>
The list of things that <i>VSS</i> 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.
<p>
For example, OLE automation is terrific (if you're an OLE developer).
Unfortunately, the power of OLE is hobbled by its complexity.
<p>
<i>VSS</i> 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.
<p>
The GUI for <i>VSS</i> 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.
<p>
There are things that you can buy for <i>VSS</i> as add-ons, that are
part of Perforce: support for multiple platforms, Y2K support (new to
<i>VSS 6.0!</i>). Moreover, there are separate mechanisms for basic
reporting in <i>VSS</i> - whereas Perforce is useable from the command-line
for basic "data mining".
<p>
It's very telling to look at the <i>VSS 6.0</i> list of
<a href="http://msdn.microsoft.com/ssafe/Prodinfo/new.asp">
"What's New in Visual SourceSafe 6.0?"</a>:
most of the "new features" are attempts to match basic functionality
that Perforce has had for several releases.
<table border=1>
<tr><td><center>VSS 6.0 "feature"</center><td><center>Comments</center></tr>
<tr><td>Enhanced File Get and Check-out<td>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.
<tr><td>Year 2000 Date Formats<td>Available in Perforce since 1997</tr>
<tr><td>New Web Capabilities<td>You <u>can</u>
publish to a web server - the Perforce WebKeeper<sup>TM</sup> plug-in
provides this functionality.</tr>
<tr><td>Label Promotion<td>This allows you to add files to an existing
label (or remove them from the label). This is something Perforce always
had.</tr>
<tr><td>Expanded OLE Automation<td>Perforce supports most common
scripting languages, e.g. perl/python/shell.</tr>
<tr><td>HTML Help<td>Perforce's manual is on the web in HTML, and the
GUI help is, well, on-line.</tr>
<tr><td>Compare Differences in Multiple Projects<td>This has been part
of Perforce since the beginning.</tr>
<tr><td>Multiple Databases<td>Perforce has had support for multiple
repositories, managed by the same or by separate servers, since 1997.
<tr><td>Filter History Information<td>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.</tr>
<tr><td>Check External Hyperlinks<td>Okay, having external hyperlinks
might be nice.
<tr><td>Edit/View Dialog<td>In Perforce, you've been able to set
the 'helper applications' for editing/viewing files, since 1997.
</table>
</ul>
<h3>
Support and Upgrades</h3>
<ul>The first <u>year</u> 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.)
<p><i>VSS</i> support is expensive: the first two incidents are
free, subsequent ones are billed at $95/incident. (You can purchase a block
for slightly less.)
<p>In addition, upgrades for <i>VSS</i> aren't cheap: $279.00/machine.
<br></ul>
<p>
<i>This page last updated on 15 June 1999.</i>
<!-- Content ends here --><!--end content-->
</body></html>