On the road to work this morning I was listening to a good podcast from SE radio, on software craftsmanship, with Uncle Bob, and during the discussion he was asked what he thought the tools of the trade were. Among his measured responses, source control systems.

I would encourage anybody not already using source control to pick one, and use it. It wont simply make your code more resilient to breakage. If you are working in a team, it will actually improve your teams communication immediately. What isn't advertised much, is that a good SCS is also a framework for collaborating on software. Suddenly conversations flare about merging changes, when to branch and label code, where shall the 'production' branch live, what will the backup strategy be, etc.

Additionally, source control is the medium in which the boy scout rule can flourish, preventing the broken windows from taking over your code base.

I could distill a bullet point summary on how to use a particular variety of source control, but instead I'll just direct you to the subversion book. The pdf and html versions are free and well worth the read. While learning how to use subversion, it also makes an excellent primer on the concepts of merge based, client/server source control which you can take to most popular systems and get started quickly. Once you've mastered SVN, other systems like git and TFS aren't a big leap in understanding.

As far as clients go, on the mac, I use textmate or vim, both are easily configured to map command line actions with keystrokes. Eclipse based IDEs generally support subversion, as does monodevelop. On windows, visual studio plugins include visual svn & ankh. I prefer tortoiseSVN, mainly because it simply extends explorer and gives a UX closer to the command line variety that I know already.

Ultimately, no matter what SCS you pick, or what client tool you choose, something is better than nothing. At the very least, it will get you thinking about the management of your biggest asset, your code.