In the big IT shops source control is rather common place. However in smaller shops or for individual developers a version control system may not be a top priority. A source control system may seem overly complicated and unnecessary. Fortunately they’re not as cumbersome as you might think and the benefits are well worth the small effort. 

So what exactly do we mean when we talk about source control, or version control systems? Basically a source control system provides a central place to store your code and a mechanism to track revisions of that code.

Source Control

One common reason people start using a source control system is when more than one developer needs to access the code. There used to be a time when our live production system served as the central repository for accessing code. Jim had a task to update a webpage so, he would connect directly to the server and make a change to the file in the live environment. Bob may have a change to make and then go do the same thing. What about quality, what if there was a mistake or a file was accidentally deleted. To avoid this Developers may keep code in another location other than the live site. For individual developers this is typically on their computer. For multiple developers, this central spot may be a shared network drive. With that risk averted what else could go wrong?

What if Jim had a lot of changes to implement. Some core functionality needed to be changed and it couldn’t be done at one time. Typically Jim would grab a copy and keep it locally until it was finished then post it. Here’s the rub, after Jim takes the copy but before he puts it back, Bob goes on the server and makes a change. Later Jim posts his changes and overwrites Bob’s code. Geez thanks Jim.

Here’s where we start to see features of a source control system come in. In this case if they were using source control, when Jim tries to put his changes in, the system would alert him that other changes had been made since he pulled his copy.

Source Versioning

So what about this versioning concept, why do I care? Have you ever used undo on your computer? You know you make a mistake, hit ctrl+z and revert back to what you had before? Here’s a question, how do you revert back to something you had yesterday or last week. If you had something versioning your files you could do just that.

Say you’re doing a website and are making some wording updates to a promotion. You post the changes and a few weeks later your client tells you there’s a law suit over that change. Apparently a customer claimed the original promotion said one thing but the company say it was something else. How do you go back and see what really was on the site? Version control.

Another scenario, you have a functional application that your client is using in production. Now you have another customer who wants to use it too. You decide to update the application to accommodate more than one client. After a few weeks of tinkering you still can’t get things the way you want. It’s functional and in your central repository but not quite right. Your client comes back and wants a change to the app in production tomorrow. Your repository copy has the new changes in it, if you make the change now it will have your unfinished changes in it. With a version control system you can pull a snapshot of the code from before you started your changes and update it without affecting your in progress changes.

Getting started using a source version control system

There are a variety of free and fee based solutions. Some of the big names like ClearCase and Preforce sometimes show up in the big companies but the free solutions like CVS and SVN are more popular. CVS has been around for ages and had a huge following. SVN, also known as Subversion, started as an effort to fix some of the challenges that were in CVS. These days SVN is very widely used and is pretty much the standard.

Lets take a look at SVN. Most systems have a server component and a client component. The server piece is where your code is stored and the client is an interface for you to access that code. SVN is no different. You can go out and grab the server components then go get a client too. You don’t need to do this at this point though. For this example and for simple setups, the Subversion client TortoiseSVN has everything you need. So go ahead, down load and install it.

Once installed create a directory to act as your central repository. In this case I’ll create one at c:\repo. Navigate into that directory and right click. In the context menu choose TortoiseSVN -> Create repository here. Just like that you have a functional source control system.

Lets start using our new system. Before we do I need to clarify one thing. We just created a setup that mimics a server configuration. While this example is setup locally, it could ba on a server somewhere. The next step explains how you access that content and keep a useable copy locally.

We’re ready now to use our SVN instance. Find a place on your computer where you’ll be doing your work, maybe c:\workspace. Navigate into that directory and right click. In the context menu choose SVN Chekout. This will pop up a window asking you where your repository is and how you want to get the contents. 

For the URL type in file:/// followed by the path to where you create the SVN repository earlier. This is not the working directory, rather the location of the repository. Since we installed this locally it will be something like file:///C:/repo but if this were on a server it could be http://someserver.com/repo

In this scenario we’re starting with the repository and pull the contents into our workspace. If you already had files in a workspace you could start there and push them into the repository with the import option on the context menu.

Using Your New Source Control System

Now that we have things setup lets try it out. Create a text file in your workspace called MyFile.txt. Add some content in it. Save and close. Depending on your version and setup the icon may differ but you’ll see a marker on your file like a question mark. This is telling you that this file is not in the repository or under source control. Since it is a new file we need to get it in there. Right click on a white space and choose

svn commit. The following popup will show you all files   that have been updated locally and are not in sync with the repository. you should notice that our file is listed, but is not checked. Since this is a new file we need to select it and have the SVN client add it to our repository. Make sure our file is checked and hit ok.  The confirmation screen will show that everything has been added and updated.

Now go back and make a change to that file again, Save it and take a look at the new icon. 

This exclamation point tells us that this file, which is under version control, is out of sync with the repository. Again right click and commit changes.

Now all is good and we get a Green checkmark.

So there you have it. The barebones basics of getting going with a source control system.

In future posts we’ll be using source control systems in our examples which will give you more context how this fits into a development process. Even with this basic setup you’ll be able to point your IDE to this local repository and follow along. Don’t just use it for our examples though, you can keep versions of any file this way. Version your wedding list, or Photoshop files. Whatever it is, revision control systems provide a lot of value.

For now happy versioning.