Developer Collaboration – Source Control

What is Source Control? Do I need it?

At first when I started learning about it, the tools (SourceSafe to be precise) were not so good and I wasn’t really impressed. It looked more like a hassle at the time. But the tools available now are so much better.

To properly answer the Question, I will first pose another question (Nigerian Style *Laughing*)

“How do I create backups while coding, In case something bad happens?”

This is a question that many of us have asked our selves and we answer them in different ways. Some of us create a duplicate of our project and then update that duplicate when we are okay with the code we have, I personally created Zip files of my code to show several stages of development. I even met people who wrote scripts to create a new numbered folder (e.g. Project_12) and copy their entire project into it. Crazy Huh? The idea of course was that if something went wrong, we would copy our last backup and continue from there. This process was chaotic and inefficient at best

Source Control was invented to fix this. You can think of it like “Shadow Copies” of your project. In other words if you overwrite important data by saving on top of previous data, you can recover the previous data. Kinda like a “System Restore”.

But that’s just scratching the surface. There’s a whole lot more to source control but I think this is the most important feature to many “lone rangers”.

When you have saved changes to a project, you can “commit” the changes to your repository. Something similar to creating a “Checkpoint” in gaming. These changes as saved as blobs and you can exchange and merge blobs with others.

Another nice feature of source control is branching. In my experience, I have come across many situations where I have developed up to a point where everything is working but would like to make some deep changes that may break my code. In such cases, I always created a separate project and make my changes there. If it works, then I’ll adopt it if not, I discard it. The caveat was that if I made changes to the original, then there would be a problem consolidating those changes. However, with source control I could create what is called a “branch” and then goof off in any way I please (Add, Edit or even Delete files). If all goes well, I can easily merge those changes. If not, I can “Restore” my entire project back to mint condition. This makes risk taking possible

Hmm, Interesting. But How do I begin?

There are numerous kinds of Source Control Systems and Architectures. The typical ones like SVN mean that all code will be stored away on servers and you must be connected to access the source code. However, Distributed source system are the rave now and for good reason. They are fast and don’t require any form of connection. You can completely work in isolation (lone ranger style) or in a team.

There are two major Distributed Source Control Systems. They are:

  • Git
  • Mercurial

The difference between Git and Mercurial is the same difference between the Linux and Windows, Android and iOS… and the list goes on.

Git – Is like a car with manual transmission, lots of settings and customization. Fully featured but has a steeper learning Curve. In many cases, you will need to use a Command Line Interface 😕

Mercurial – On the other hand is like a car with automatic transmission, Its user friendly, relatively easy to use  but a good amount of functionality is kept out of your reach to simplify things.

Picking one is a matter of choice. Git is more popular and has wider support. In fact, Git is the only supported source system for the popular Github. Mercurial on the other hand is easy to use and has good GUI support for Windows. Mercurial users can use Bitbucket for online collaboration but its not as popular or feature packed as Github.

Another thing worth noting is that with Github, Only open source projects are free so you will need to pay a rental fee to create private repositories that only you or people you invite can view. Bitbucket on the other hand allows you to create both closed and open source projects for free.

Personally, I use both but tend to lean towards Mercurial because of its better GUI tools and Better Integration with Visual Studio. Below are the tools you will need for the different source systems.


  • TortoiseHg – GUI Tool for Mercurial
  • VisualHg – Visual Studio Plugin (optional)
  • P4Merge – Document Merging Tool (optional)


On a final note, If you are new to all this, I suggest that you take time and research them. Learning Mercurial with Tortoise Hg is a very good place to start. It may seem like a hassle but this will certainly revolutionalize the way you write code and will pay off big time on the long run.


About Ody

Web Developer/Programmer and Hardcore Gamer. Mainly interested in the Web and Web Technologies

Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s