VSS 2005 vs Subversion
I recently was asked to form an argument for switching my company’s source control from VSS 2005 to Subversion. This is what I came up with…
Subversion is obviously not the only alternative to Visual Source Safe, but it is a very solid one, one which I have personally used over the past several years with ease. Other source control options for us would be to use Perforce or MS TFS, both of which are pricey, especially TFS. However, Subversion is free and largely recommended by a vast number of people, especially when compared to VSS. Subversion is also supported by a large volunteer online community.
I have chosen Subversion over VSS mainly for the following reasons:
True Atomic Commits
A commit containing multiple files is treated as a single transaction, and a new revision all in one. Much like a database transaction, if one file fails to commit, they all fail – which is desirable to assure that project-wide changes being made which depend on each other are all done at once.
Copy-Modify-Merge
VSS’s lock-modify-unlock model makes it difficult to collaborate on rapidly changing files/projects. Subversion uses the copy-modify-merge model (aka optimistic merge), which better allows for multiple developers to work on the same project. More often than not, optimistic merge is a time saver over the lock-modify-unlock model. It is possible to lock a file from being committed by others in Subversion as well.
Easy Branching/Merging
Subversion allows for easy branching and merging of projects. This allows for easier development of new features or new versions of the product.
True Client-Server Model
VSS uses a network share for the repository database that relies on the developers having, basically, full control of the files therein. Subversion uses a true client-server model via http(s) or the proprietary svn protocol. I recommend the https protocol for compatibility and encryption.
Data Corruption with VSS
With VSS, it’s not a question of if the repository database will become corrupt and lose data, it is WHEN this will happen. Your source repository is supposed to be a rock - if a developer’s workstation crashes, you should only have lost HIS changes. You shouldn’t lose random files and data from the repository.
If you have developers spread across multiple time zones, the very act of both of them checking in can corrupt the database if they check in too close together, in the wrong order.
API
There is no good, usable, easily available published API for VSS and 3rd-party tools are weak for the most part. Subversion is open-source and inherently widely supported via API and many third-party plug-ins and additions.
Other notes:
Microsoft recommends that VSS is not suited well for large projects, but rather small projects with small teams. Microsoft themselves haven’t used VSS (in any widespread capacity) in over 10 years. If MS doesn’t believe in their own software, why should we?