I am not a code repository expert, but I've used Visual Source Safe (VSS), CVS, SVN (Subversion), and to a small extent Git. I will shortly be moving to Microsoft Team Foundation Server. You can argue with people about their particular favorite platform until you are blue in the face, but in the end, if you don't have a code repository, get one and use it as soon as possible. This will elicit a big "Duh" from thousands of you out there, but you would be surprised how many shops still use a mapped drive or back up the code onto CD or DVD periodically.
I am most familiar with SVN, and while it isn't perfect, it is free and fairly well documented. I am very much intrigued by what I see from Git (it is a distributed control system that is gaining in popularity), and I plan to present something on it once I have more time to research it and make some recommendations. However, if you are a small to mid-size shop, chances are you have people who have used subversion elsewhere. The biggest complaint many people had about SVN was how hard it was to install for those of us (and I count myself one) who are not network and hardware gurus. That has changed with CollabNet Subversion Edge. CollabNet, the creators of Subversion, have put an easy to use web front-end on SVN administration and wrapped it up into an easy to install Windows installer. For the average development team this should be more than enough as it is both free, and limited only by the drive space you give to your repository. It integrates with LDAP, and keeps itself up to date.
If you are still using Visual Source Safe, while it is better than nothing, it has been discontinued by Microsoft and has problems. Additionally, I feel that it discourages collaborative coding by allowing people to check-out files and projects for long periods of time without checking them back in. Initially this saves on merging issues, but in the long run, I feel it slows a team down. There are additional technical issues you can read about on Alan De Smet's webpage. The basic feel I get from reading around is that VSS is itself an anti-pattern.
Here are some principles I would follow with whatever you choose to pick as your source code repository and versioning tool.
- It is better to have the code worked on and checked in in small chunks into the trunk. This is easier if the team is co-located. If not, you may have to create sandbox-branches for developers and communicate what needs to be merged differently than simply turning to your programming team and telling them.
- Everything needed to build your project should exist with the project (or be available from a tool like Maven). A project needs to be built with a single command and an argument for debug, production, etc. releases.
- You must require people to enter some form of comments into the repository tool (especially after the inital check in). Preferably this will include some kind of link back to a change request or bug tracking system.
- Create two branches at the time of release for the project. One should be a "tag" (a snapshot that is NEVER edited afterwords) and a true branch where you will work on correcting bugs and will eventually merge back up to the trunk. This should allow you to fix issues you find with a release while still moving forward on the next release. However, merge often and kill off branches without mercy when you are done with them.
- Put configuration information, release notes, and some basic documentation with the code, but think about investing in a CMS (Content Management System) like Alfresco or SharePoint for your end-user and technical-user documentation. Unlike Humble and Farley, I don't think raw Subversion is the most appropriate place to do document collaboration and content management. It works, but there is so much more you can do with a real CMS.
- Keeping with the Agile concepts of maintaining transparency, shared ownership, and allowing for honest inspection, I would provide at least a read-only access to your code for other developers, managers, and even well-informed, non-technical members of the team. Extra eyes on code can only help. Hide nothing as "sunshine is the best disinfectant."
- Avoid checking in anything but the code, the required resources, and the build script. Let the developer import the resources and create their own Projects, Solutions, Workspaces, etc. Everything should be based around your build script needing one and only one command to build the application. This will set you up well for the next steps in automating your code production line.
In keeping with trying to keep this general, I'm not going to recommend a specific toolset. However, I've used Tortise SVN (from Windows explorer), the various Eclipse plug ins, and AnkhSVN from Visual Studio for SVN. I've used the command line as well and plain old cvs commands. AnkhSVN works very well for anyone doing .NET development (and it is free). Chances are you may have to use a variety of clients depending on your situation. I'm in a heterogeneous environment so I use Eclipse, TortisSVN, and AnkhSVN for a variety of tasks.