Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code

I have been thinking about this for a while now. I speak around the Midwest about Behavior-Driven Development and as I poll groups of developers there is one thing I notice: there are a lot of things that I consider “givens” that quite a few people aren’t doing. I’ve been lucky enough in my last two jobs to be asked to basically build a development shop. I did tons of research for both and there are some practices that are going on in the industry that really should be just common practice. So maybe this is a “best practices” list, but I think of it more of a “standard practices” list. As we discuss each tool or practice, we’ll discuss what options are out there as far as tools for achieving the desired results. We’ll discuss a little of the pros and cons of each, and I’ll show you the toll/practice I use most often.

Getting Started

Let’s start at the beginning… thanks captain obvious. There are still some teams that are not even using source control. I know it sounds hardly credible, but I promise you that it is true. There are people who sync their copy with they team-mates’ by copying files to a network share. This is not meant to impugn those developers’ works. They might be mighty fine developers who’ve just never been exposed to a Source Code Management system before. Well, let’s expose you…

Source Code Management System is just a fancy name for source control. You may have used Visual Source Safe (VSS), Subversion (SVN) or Concurrent Versioning System (CVS) before. Each of them have plus and minuses, but let’s look at the standard features of (just about) any CMS.

Check-In & Check-Out

Of course, the most basic thing is the ability to check-in and out source code from your CMS. Making it easy to upload only the changes and have teammates (or even you on another machine) to be able to get those changes is one of the most basic parts of the SCM systems. Most SCM Systems check-in to a central code repository and it uploads only the changed files and keeps track of what’s changed from version to version. Git, however, is a distributed SCM meaning there really ISN’T a central repository (although you can clone, and fetch from an origin repository). Let’s just start simple.


The next thing, is being able to merge changes when you and another member of your dev team make changes to the same file. If you both change the EXACT same line, you will cause a conflict, and have to resolve it. Most SCMs have some way of setting the “Locking” type. It will be either “Optimistic” or “Pessimistic” locking. Optimistic Locking is just like it sounds, the SCM is being optimistic that any conflicts within a file will be resolvable by you, so it doesn’t lock the files and keep others from working on them. This can be a little hairy, because you WILL have conflicts and you will have to resolve them. Pessimistic Locking, on the other hand, doesn’t trust developers and only lets one person at a time edit each file, by locking the file when someone checks it out.

I prefer optimistic locking. Pessimistic sounds really safe and more desirable, until Jim goes on vacation and forgets to check-in his files so that others can work on them. It’s also problematic when you legitimately need to work on the same file. I need to make a change to file X so I can see how it effects file Z that I am currently working on, and Jim’s working on file X at the moment. The biggest downside to optimistic locking is the conflicts, and to be honest, it is NOT that hard to resolve conflicts. there are tools for the SCMs that make it easy to inspect the differences and accept/reject/merge changes.

Rolling Back

You might find that when writing some code for a feature, you’ve introduced major holes in the rest of your application. (This can be avoided by using TDD/BDD and doing a good “Check-in Dance”, but we’ll get to that.) If you find yourself in the situation where you’ve broken so many things in your code that you wish you could just get back to the way the system was before you did all this, you can. All SCMs support versioning and rolling back. Some make it very easy to do, so ctrl-z is not your only option anymore.


Branching is another feature of modern SCMs and it allows me to take a snapshot of a codebase and create a fork, so that I can try and fix a bug in without changing the code that is in the “trunk”. Once any bug fixes or enhancements are made in that “branch”, you can merge those changes back into the trunk. As a matter of fact, there are lots of teams that branch for just about everything. I think that’s a little drastic, but if it makes you comfortable to branch every spike, every bug and every new feature, you are certainly welcome to.

There are lots of SCMs out there, both free and paid. I have actually never used one of the paid SCM systems (Perforce, Bitkeeper or SourceGear Vault), there are lots of great free SCMs to get started with and if you find that you need to do something that you can’t get in your free solution, then look at the paid systems. The main free SCMs are Subversion and Git. Microsoft’s Team Foundation Server also has a SCM built into it and it integrates nicely with Visual Studio.

My Choice

I choose Subversion. I use VisualSVN Server to set up the Subversion server on a server machine, and then I use TortoiseSVN as my Windows client. So far, SVN and Tortoise have caused me very little friction. Branching and Merging can be a bit tricky when you first get started, but once you get the hang of it, it becomes easier. Subversion also comes with a free book and has been around for quite a few years now. There is also a huge number of users using SVN for their SCM, so finding help can be very simple.


So we talked about the basics of an SCM System and some of the choices and we made the choice to go with SVN. Now what? In the interest of not letting this post get any longer; in the next post, we’ll talk about installing VisualSVN and Tortoise and we’ll create a repository to start checking our code into.

On to part 2

Posted on Friday, September 4, 2009 12:53 AM | Back to top

Comments on this post: Let’s Build A Dev Shop (Part 1 of n)

# re: Let’s Build A Dev Shop (Part 1 of n)
Requesting Gravatar...
Thanks for the blog. I look forward to reading the rest. Although, I must admit that I'm one of the lucky developers that had never used an SCM prior to this year. We were a smallish shop and each developer worked on individual projects. However, we have recently stepped up to Subversion and TortoiseSVN and I'm loving them. Always looking for new tips and tricks, though.
Left by dotnetBRG on Sep 15, 2009 8:08 PM

Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: