Sublime Subversion
just posted a summarizing the current revision control landscape. Brian does a great job of walking through the key differences between centralized (i.e. Subversion or Perforce) and distributed (i.e. Git or Mercurial) systems, not only from a technical perspective but also workflow and culture considerations. The result is a very concise, but thorough guide to choosing a system that will best fit the requirements of your team.
Toward the end of the article Brian reminds us just how young our field is and how much more evolution there is to come. Revision control being such a fundamental component of software development I think we all need to work toward standards or community adopted best practices that will work across products and platforms. This will make it easier to train new developers, encourage consistency across organizations, and ease the pain of transitioning from project to project, or company to company.
When moving to SVN from VSS there are really two different aspects to consider: technical, and social.
Technically, the answers are pretty straight forward. You need to decide where the SVN repositories will be hosted, how they will be served, and how permissions will be managed. You also need to decide whether or not you want to import your existing VSS repositories, and how much of the history you want to preserve. Finally, you need a client for your users – typically and optionally a Visual Studio plug-in like or .
The easiest ways to set up a SVN server is to use one of the pre-packaged installers like , Server, or . All of these will install Subversion and do a lot of the basic configuration for you.
Here are a few resources on the technical side:
Now, the social side may be a little more difficult. The biggest change is that VSS works with a check-out, edit, check-in model where SVN works with a edit, merge, commit model. This takes some getting used-to by the developers but ultimately it’s a better model in my opinion. With SVN, you essentially have the entire code-base checked out by everyone, all the time. You are free to make whatever changes you want without checking anything out. Then, when you are ready to commit your changes, you merge them with the latest version in the repository, and commit everything at once.
There are a few major benefits by taking this approach. One is that there are literally no roadblocks between a developer and the work he/she needs to do. I don’t need to wait for a file to be checked in, and if I want to make large changes I don’t need to worry about getting in anybody’s way.
The other major benefit is that each commit can represent a self-contained body of work: a feature, a bug fix, a unit test that passes, etc. All files and changes related to that body of work are contained within a single commit and it’s easy to look at the repo history and see why files were modified and how modifications relate to each-other. This is much harder to do in VSS because people usually check in file by file. Or, if they do check in multiple files at a time, it is probably because somebody else needs to edit one rather than them being finished with their particular feature.
Source control is an incredibly valuable tool for software development, but most people don’t think of it that way. Managed correctly, source control is a safety net giving developers an enormous amount of freedom to experiment, tinker, and implement with the knowledge that they can always go back if necessary.
In my opinion, you can’t do source control correctly with the check-out, edit, check-in approach. At least, not with a team of any significant size. So it’s worth some short term pain in terms of developer education for long term benefits.
has a on source control overall. In he discusses the differences between these two approaches.
It’s worth pointing out that SVN does support locking which lets you get close to the check-out, edit, check-in model typical of VSS. But, I’d still recommend biting the bullet and adopting the other model.
