A few days ago, I took an interesting customer call - the customer was looking to move from Visual Basic 6 to Visual Studio for .Net and was trying to understand their options.  At the same time, they wanted to implement a source code control (SCC) system - they were looking to increase the number of developers on the project and they were already having a difficult enough time as it was trying to coordinate who would be modifying which file manually with only 2-3 developers.  They asked me about Sourcesafe which would have been included in their MSDN Premium subscription. 

I think we've all been there - a project without source code control - maybe the project was very small or you had a couple of developers working on a project - maybe you inherited a project in that state  - when I first started working at Xtras.Net I was in just that situation - many, many code components, websites, and back-end databases and all of it without source code control. 

The first thing you might notice when working without source code control is that your system is very fragile to change. 

• You're always working on the production code itself, or on a copy of the production code.  If you're working with a copy of the production code, how many developers can access it, what if they want to make conflicting changes? So you end up trying to make your own SCC system - maybe each developer has their own copy of the production code, and they can only change certain parts, and then comes the pain of trying to integrate those changes back into one completely working codebase. 
• So, why not just work on the production code itself - well you end up causing another problem - what if the changes you want to make will take 6-8 weeks to implement - you start making substantial changes to the code - and then an end user calls up with a major problem in the copy of the application you just deployed - without an SCC tool, you don't have any way to re-create the copy of the application you deployed - you can't fix the problem and re-deploy that older version - now you've got to either abandon the changes you're working on to fix that bug and hope in your rush, you don't create new ones, or you have to move forward with your proposed changes and leave the user without a solution to the problem for 6-8 weeks. 

Those are the types of problems Source Code Control tools were designed to solve.

Getting started with Source Code Control can be a little intimidating at first - I started out like a lot of Microsoft developers and used SourceSafe as my first SCC tool.  We had a small team and it was "free", but pretty soon I kept running into problems of corrupted files and improper file locks - a lot of frustration and sleepless weekends trying to re-create lost segments of code.  Those initial experiences turned me off to SCC tools for a while. A couple of things turned that around.

First, I read Mike Gunderloy's book - Coder To Developer it walks you through in a very clear way the benefits and options of using a Source Code Control Tool .  He takes you through each of the major SCC tools that were available at the time and gives you a feel for each.  I also read Eric Sink's blog entry on how to use SCC as a developer (Source Code Control HOWTO) - Eric Sink is the President of SourceGear which develops Vault. It is built around a SQL Server back-end, so you don't have the file issues you do with SourceSafe.  Xtras.Net has been using Vault for years without problem.

There are many other Source Code Control tools out there - many are commercial, but there is also a large group of open source SCC Tools you can check out as well - please take some time and see what Source Code Control Tools can do for your current or next project.

Source Code Control Products at Xtras.Net
Vault at Xtras.Net