Source Control Thoughts
I was informed recently that I may have to contribute to a project that’s using VSS… I immediately thought of this quote about VSS by a MS employee “Visual Source Safe? You’re better off printing out your code, putting it through a shredder, and lighting it on fire.”
Just to be fair, if you have your source stored in Visual Source Safe, that is better than nothing. But you can do much better with little effort.
VSS still doesn’t have atomic commits to the best of my knowledge. What other kind of database that stores information as critical as your source is allowed to get away with non-atomic commits?
If you have had your source stored in VSS for at least a year and you are the admin, how many times have you had to run the database analyzer? And how many times has it told you that your repository or a block of files have been corrupted? If your repository has been corrupted at least once, you should have red flags all over the place.
Think of this in terms of your regular databases. If your SQL Server/Oracle/MySQL databases frequently gave you “your database has been corrupted” messages would you keep using that database?
So once again, you can do better. Here are two good options – there are many more.
I think the easiest sell is using a tool like Subversion. It is a stable and widely used repository. There are excellent client and admin tools available for many platforms. I have used Subversion off and on for the last 4 years and heavily for the last 2 years and have been very pleased with it. It is stable, reliable, accessible and it is actively being improved and developed.
If you are a larger company in the Microsoft space and you have plenty of money budgeted for your source control strategy you might look at Team Foundation Server. I’m using this on an open source project and have been satisfied with its performance and usability. My only gripe so far is that it does poorly in a disconnected scenario – Subversion really shines here.