Reasons to switch from SourceSafe to Vault
- 30 March 2004 -- Revised for the Vault 2.0 release
- 14 July 2003 -- Originally published
A friend complimented me for not doing any "blatant merchandising" here
on my weblog. My reaction was one of surprise. Have I really been
forgetting to do blatant merchandising on my weblog? :-)
Seriously folks, this article will be the exception, not the rule. Skip
this one if you're not interested in windows version control tools. But
people frequently ask me why they should consider switching from SourceSafe to
Vault, and I would like to answer that question here.
SourceSafe has developed a reputation as
product, often being referred to by derogatory nicknames like "SortaSafe" and
"SourceUnSafe". :-) Actually it's not really that bad, but for
many developers, data corruption by a source control tool is unforgivable.
Vault was designed from the beginning with reliability as the number one
priority. All repository data is stored in Microsoft SQL Server 2000,
providing the Vault server with a robust and trusted data store. We also
have an extensive and highly abusive test suite which verifies that the
integrity of the repository is preserved, even under pathological
SourceSafe just does not work well over the Internet. Its design
is not based on a client-server approach, so it can be extremely slow when
used over network lines with high latency or low bandwidth.
Our own SourceOffSite
product has become very popular as an add-on which solves this
problem. (BTW, a note to users of SourceOffSite: We
recognize that many people will remain with SourceSafe. We are not
abandoning SourceOffSite. In fact, we released version 4.0 in March
Vault was designed for the Internet from day one. It was built
entirely in C# using the .NET Framework. The Vault server is a
collection of XML Web Services running under IIS. The communication
between client and server is HTTP, optionally with SSL for security.
Furthermore, Vault's client-server protocol was designed for the
constraints of the Internet. Instead of sending the full contents of a
file, Vault can usually save bandwidth by sending only the bytes which have
changed. This exchange of "deltas" is used in both directions, from
server to client as well as from client to server.
As far as we know, Vault is the only version control system designed
specifically to replace SourceSafe. In every way possible, Vault
presents a familiar interface with familiar terminology. Every major
SourceSafe feature is supported, including things like Share and Pin.
Our import tool will move your SourceSafe database into a Vault repository,
including all historical information.
Visual Studio .NET integration
Just like SourceSafe, Vault can be used within Visual Studio .NET.
This functionality is currently limited because Visual Studio's support for
integrated version control is rather poor. As a member of Microsoft's
Visual Studio Integration Program (VSIP), SourceGear will be one of the first
to provide improved integration when new capabilities become available from
Folder-level Share and Pin
Vault offers some subtle yet powerful improvements to the Share
command. Just as with SourceSafe, a shared item is a single item which
appears in multiple places. But SourceSafe can only share files, not
When you share a folder in SourceSafe, what really happens is that every
file underneath that folder is shared, recursively. On a file-by-file basis,
the effect is the same. But if you add a file to the shared folder, it does
not appear on the other side of the share. The files themselves are shared,
but the system has actually made distinct copies of the folder in which they
In Vault, this share operation is implemented at the level of the folder
itself. Just like a shared file, there is really just one instance of a shared
folder even though it appears in multiple places. If you add a file to a
shared folder, the new file will appear everywhere that folder has been
shared. The same applies if you add a subfolder, rename something or delete
something. Regardless of what happens to that shared folder, it will be
exactly the same in each place that it appears.
This makes it much more useful to share entire libraries or modules between
teams. For example, suppose your project decides they want to make use of a
class library being developed by another team. You can share the folder
containing their entire code tree into your own tree. Using SourceSafe, when
the other team adds a file to their library, your build breaks. Using Vault,
any change they make will show up in your tree as well.
Pin works at the folder level as well. Suppose you have shared another
team's library into your tree but that team has since gone astray and begun
destabilizing their code. You can pin your shared instance of their folder to
the last revision that was stable.
Atomic checkin transactions
When you checkin a set of changes to the Vault server, the
operation is performed as a single atomic transaction. If one item fails
for any reason, then the entire transaction will fail, and the repository will
be left in the condition it was in before the transaction was attempted.
This important feature, unsupported by SourceSafe, prevents a
half-failed checkin from corrupting the contents of the
There are two primary patterns for working with a version control
tool. One way is to checkout each file before editing, often with an
exclusive lock that prevents others from editing the file. When you're
done with the file, you check it back in, releasing it for use by
others. We call this the "checkout-edit-checkin" style of
development. Most SourceSafe users work this way.
Another approach is often called the "edit-merge-commit" style of
development. In this style, files in your working folders are usually
left in a writable state when you retrieve them. When you want to edit a
file, you simply do so. The version control tool will automatically
notice that you have made changes. Your changes are submitted to the
repository when you "commit" them. However, you may not commit your
changes if anyone else has modified this file since the last time
you retrieved a baseline from the repository. In this case, you must
retrieve the latest changes and merge them into your working copy of the
file. After doing so, you may proceed to commit your edited version of
the file. The source control tool facilitates this process by helping
keep track of the versions and making the merge simple.
Users tend to have extremely strong and divergent opinions about which
style is better. Many users do not trust the "edit-merge-commit",
preferring the safety of knowing that a given file may never be modified by
more than one person at a time. In contrast, those who have used the
"edit-merge-commit" cannot imagine returning to the more tedious
Vault was designed to allow each user to make this choice
individually. The default behavior is "checkout-edit-checkin", which
will be most familiar to SourceSafe users. But those who prefer
"edit-merge-commit" are free to configure their client accordingly. We
informally refer to this configuration as "CVS mode", since the
"edit-merge-commit" style of concurrent development was made popular by
The merge features in Vault 2.0 are much improved from Vault 1.x and
significantly more powerful than SourceSafe.
For file-level merging, we provide SourceGear DiffMerge, a standalone tool
which supports diff and 3-way merge with a graphical display. For those
who prefer to use other diff or merge tools, Vault allows the user to
configure an external application.
The Merge Branches Wizard makes it easy to migrate changes between folders
in the repository.
New in 2.0: Displays an annotated view of a file, showing which user
last modified each line.
New in 2.0: Allows basic browsing of the contents of a repository
using any web browser.
Vault Client API
A source control system is not just a tool, it is also a platform.
Many users need the ability to build custom solutions which interact with
their source control repositories, for things like reporting
and automated builds.
SourceSafe frustrates in this regard, offering a subset API which is
incomplete and sometimes unreliable.
SourceGear provides the Vault Client API, which allows our customers
to build custom clients using the same API we use. We cannot yet promise
that the API is frozen. We can't brag about the completeness of the
documentation yet. But we do provide the source code for our
command-line client as sample code. And we try to answer every question
about this API on our public mailing list.
Building Vault on SQL Server brings other advantages besides
reliability. Using the query capabilities of SQL, Vault's History
Explorer offers powerful new ways to view what the changes that have happened
in your repository.
An important pillar in the philosophy of source control is that the
repository should include every change which has ever happened.
Destroying data permanently is equivalent to rewriting history, and should be
SourceSafe makes this sin far too tempting by providing a "Destroy
permanently" checkbox in the dialog used for deleting a file.
Vault's design is safer. Anything which permanently destroys
historical information is called "Obliterate". These features can only
be performed from the Admin Client, not from within the regular user
Integrated bug tracking
Source control and bug-tracking go hand-in-hand, but SourceSafe is
ignorant. Vault currently offers integration with FogBUGZ. In conjunection
with Vault 2.1, we will provide a .NET port of our own bug-tracking system,
supporting full integration with Vault.
Honesty and Openness
We try to be forthcoming about the areas where our product needs to
improve, to ensure that expectations are appropriately set. We would
rather lose a sale than obtain a disappointed customer.
Over and over, our customers tell us how much they appreciate this posture
of honesty. From our point of view, nothing else would make sense.
We know our customers are smart people who develop software just like we do,
so we give them the facts. If we can't win your business today, we'll
win it tomorrow.
SourceGear is now over seven years old Our list of satisfied
customers includes hundreds of names you know, from every industry, from all
over the world.
In October 2002 we were named #156
on the Inc 500, Inc magazine's list of the fastest growing private companies
in America. Microsoft itself was once a winner of this same award.
SourceGear is definitely still a small company. Many of our
customers are several orders of magnitude larger than we are. But
companies large and small continue to buy from us with confidence. We
are profitable and conservatively-managed, and we plan to be around for a very