Recommended SCC software evaluation criteria
Of course not all source code control software is made equal. Any choice of any tool is best done by first evaluating the alternatives.
There are a few tools or technologies to choose from when thinking of deploying your own source code system. A single chapter can't possibly detail all of the possible tools and technologies that are available, so I'll just give some examples of some popular Windows options.
If you have an MSDN license, the first thing that comes to mind is Team Foundation Server (TFS). TFS is much more than just source code control (about one-ninth of its features). TFS also has features such as work item tracking (including requirements, defects, tasks, and so on), reporting, collaboration (implemented with SharePoint), build automation, and project management. If your team needs more than source code control, you may want to look at TFS. The caveat is that the current licensing model requires client access licenses (CALs) in certain circumstances, and thus can get pretty pricy for relatively smaller teams. TFS roughly uses the lock/edit/check-in model (by default it checks-out rather than locks, but still prefers an available connection to the SCC server in order to perform a check-out). TFS usually requires separate installations of SharePoint and SQL Server in order to perform collaboration and store data.
Another popular choice on the Windows platform has been Subversion (often referred to as SVN). SVN is an open source SCC system. Technically free, some third parties such as VisualSVN offer redistributions of the system that includes support options. Generally, the SVN distributions only contain SCC, but many third-party tools integrate to offer things like collaboration, build, and work item management. SVN uses its own database schema to store data, so only one installation is required to get started. To integrate with other tools, of course, requires installation of those tools and potentially manual integration steps. Tools like TeamCity will integrate with SVN quickly and easily to perform automated builds.
Given the focus of the book, I'll focus on criteria that would apply only for developers working in Windows.
Workflow model
Each SCC tool uses a specific workflow model: lock/edit/check-in or edit/merge/commit. Each model has some caveats. Lock/edit/check-in assumes that you have a constant connection to the SCC server in order to lock files or check them out. Although some of these tools attempt to deal with being disconnected in certain circumstances; during periods of network disconnection (failure or off-site) these technologies can be troublesome. TFS is an example of one such technology.
Total cost of ownership
Total cost of ownership (TCO) is important. If you decide on a particular brand of SCC and deploying that SCC is too expensive, you will run into issues very quickly in the deployment. Consider the various aspects of cost when evaluating SCC options. Make sure you know the costs of the various options and requirements before you take the plunge. Be sure you account for CALs (if necessary), server costs, resources to deploy and maintain third-party tools, integration costs, and so on.
Integration options
SCC is its own beast, but, it can integrate well with other workflows or tools. Work items, for example, integrate well with SCC-type workflow because you're often working on a specific work item when you commit changes. You may want to associate those commits with a work item and close the work item when all of the changes have been made.
There are other tools that integrate with various SCC offerings. If you think your team needs tools that might integrate, be sure to include those needs when evaluating particular SCC offerings.
Team dynamics and location
Deciding whether you can use lock/edit/check-in or edit/merge/commit depends largely on the organization of your team. If your team is occasionally or mostly disconnected, a lock/edit/check-in model may be problematic for the team. If members cannot lock or check-out a file as they edit it, then checking-in becomes extremely time-consuming because every commit becomes a merge operation.
Self or third-party hosting
Over the past few years there have been many companies that have started to offer source code control server hosting. I'm not going to provide an exhaustive list, but some of these companies include: GitHub, Bitbucket, Unfuddle, TeamDevCentral, Phase2, and Assembla.
Getting up and running with a self-hosted SCC system could be cost prohibitive, require resources you don't have, or otherwise take time you can't make available, so consider using third-party SCC hosting.
Authentication
Each SCC has specific authentication needs. TFS uses Windows, built-in authentication which could be Active Directory, NTLM, and so on. Other tools may have their own authentication scheme or provide something that integrates into Windows authentication. If you need something that doesn't tie you to a specific authentication scheme, be sure the SCC system supports that option. For example, if you want to work with team members in and outside of your organization on different domains or workgroups, be sure the tool supports that.
Context: Given the choice of which SCC technology to use.
Practice: Thoroughly evaluate all alternatives based on needs.