VSS or SVN for a .Net Project?
At work, one of the head managers asked me to research on what could be the benefits of changing the current source control server (Visual Source Safe) of my project to SVN.
I really don't have anything against SVN, actually I kind of dig it, but in my humble opinion, change to SVN will not bring any significant benefits to the project, and will force us to use some third-party tools to manage the source control from the Visual Studio (we develop using mostly Microsoft tools only).
So, as a first step in my research, I ask you: what could be the benefits of switching from VSS to SVN?
Answer
SVN is more popular than VSS and has lot's of advantages. VSS is old and outdated.
- Why Not VSS
- Visual SourceSafe: Microsoft's Source Destruction System
- Source Control: Anything But SourceSafe
- Visual SourceSafe Version Control: Unsafe at any Speed?
Many developers nowdays are moving from VSS to SVN. If you will search for "SVN" and "VSS" in Google, it will show you lots of articles related to VSS to SVN migration.
- VSS's lock-modify-unlock model makes collaboration on rapidly-changing files a major headache. Plus the overhead of needing an admin to unlock files that someone has checked out while they're on vacation.
- With VSS, it's not a question of if you'll lose data - it's WHEN. 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
- VSS hasn't been maintained by MS in over 6 years. Can you even get support for it anymore?
- Depending on your backup tools, you may not be able to get a complete backup of your VSS repository if you have just one person left logged into the server (meaning they left their dev tools open, or left the VSS client running).
- VSS requires that all users have nearly full control, at the filesystem level (NTFS permissions), of the files that make up the repository.
- There is no good, usable, easily available published API for VSS and 3rd-party tools are weak for the most part.
- Merging sucks in VSS.
- VSS: If you have developers spread across multiple timezones, the very act of both of them checking in can corrupt the database if they check in too close together, in the wrong order.
Now, this isn't to say that Subversion is faultless - there are certainly things it could do better, and things it doesn't do at all. But all the people who worked with VSS and SVN most likely will never come back to VSS.
If you will choose SVN. Here is a list of tools you may need:
- AnkhSVN is a Subversion SourceControl Provider for Visual Studio.
- RapidSVN is a cross-platform Subversion client.
- TortoiseSVN is an easy to use SCM / source control software for Microsoft Windows and maybe the best standalone Subversion client there is.
- VisualSVN is a Visual Studio plug-in that integrates Subversion and TortoiseSVN seamlessly with Visual Studio.
- VisualSVN Server is a package that contains everything you need to install, configure and manage Subversion server for your team on Windows platform. It includes Subversion, Apache and a management console.
Here is a great book on this subject: Version Control with Subversion by C Pilato
Another good alternative to VSS and SVN is SourceGear Fortress which has Issue Tracking system in addition to source control - all in one. Or SourceGear Vault - source control only. Also there is SourceAnyWhere solution. If you need Microsoft solution than go with TFS instead of VSS.