2003-07-14 13:47:03

Reasons to switch from SourceSafe to Vault

Revision history:

• 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.

Reliability

SourceSafe has developed a reputation as an unreliable 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 conditions.

Remote access

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 2004.)

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.

Painless transition

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 Microsoft.

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 folders.

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 reside.

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 repository.

CVS mode

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 "checkout-edit-checkin" approach.

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 CVS.

Merging Features

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.

Blame

New in 2.0:  Displays an annotated view of a file, showing which user last modified each line.

Web Client

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.

History Explorer

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.

Obliterate

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 strongly discouraged.

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 client.

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

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 long time.