VSS is well known for corrupting its database.
Vault was designed from the beginning with reliability as the number one priority. All repository data is stored in a Microsoft SQL Server database, 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.)
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
Vault is perhaps 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 Integration
Just like SourceSafe, Vault can be used within Visual Studio, including VB 6, VC++, VS 2003, VS 2005 and VS 2008. We provide the traditional MSSCCI style integration through the Vault's Classic Client integration. In Vault 4.x and later Vault also offers Enhanced Client integration. As a member of Microsoft's Visual Studio Integration Program, SourceGear has been one of the first to provide improved integration with new capabilities which are now 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.
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 provide the source code for our command-line client as sample code. Support is available via our online forum and email to support at SourceGear.com
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 users who wish to have integrated bug tracking can upgrade to Fortress, which has the source code features of Vault with item tracking and other ALM featuares.
Web Client
Many users want to access their source code from a web browser. Vault has a simple, secure web client that allows users basic read-only access to their Vault repositories from a web browser. From the Vault Web Client users can view the Vault repository structure, view individual file histories, view difference from the previous version of a file, view Blame, and get individual files.
Blame
When someone checks in a change that breaks your build it is nice to see exactly who did it
Vault provides a feature called Blame which is available from both the GUI client and the Web Client. Blame displays an annotated view of the file showing which user last modified each line.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.
Support
Visual SourceSafe is an end-of-life product. The last major release was in 2005. SourceGear continues to update Vault in new releases, including Vault 5.1 in 2010. SourceGear provides prompt, accessible support through its online support forum, and by email and phone.
SourceGear
SourceGear is 15 years old. We have weathered the storm of the tech recession, and the company has never been stronger. 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.
updated 2/5/13 - lbauer