Matt Tuttle


Why I use a Distributed Version Control System (DVCS)

Why I use a Distributed Version Control System (DVCS)

If you are a programmer you probably already have a good understanding about version control (also know as source code management) and have probably used something like Subversion, Perforce, ClearCase, Visual SourceSafe or something of that nature. Each of those run on a server and allow multiple programmers to check out and check in changes to ease code merging and branching. In my experience there is usually at least one person who has to make sure the software plays nice and when merges don't go well that person is responsible to manually make the changes so that everyone's code works as expected.

I used to use Subversion for all my personal projects but I couldn't stand setting up a server and how awful the code merging was when I wanted to merge a test branch. It always bothered me that merging wasn't based on the actual data in a file and more on the line numbers. If you make two changes on line 153 and try to merge the file together it will ask you which one to keep or else you have to manually fix it before changing. All these frustrations lead me to take a leap into the DVCS world by using a tool called Mercurial in my workflow.

The reason I chose Mercurial was because I had heard it was similar enough to Subversion that it would allow me to learn new things as I go without having to learn an entirely new tool (IE. git). I immediately noticed that Mercurial allowed me to setup a version control system right within a project I was currently working on. Absolutely no setup was needed I just had to use "hg init". I then added all my files and committed them to the repository and viola I had version control working. Just to show you how easy it is, here are the commands I used.

hg init
hg add
hg commit -m "Initial commit"

The next thing I wanted to do was work on my laptop since I was going to be travelling that day so I popped in a USB and cloned the project to my USB drive. I made a bunch of changes and commits that day and when I was finally back at my desktop I simply pushed the project back to my desktop and continued coding. The best part of the process was the fact that I didn't have to be connect to a server at any point to make my changes so I didn't have to wait to make commits.

hg clone usb-folder
hg commit
hg push
hg update

Finally I had my code to where I wanted it it and shared it with a friend. He decided to make some minor tweaks to my binary files and I continued working on the code. Neither of us was working from a centralized copy of the project we just kept working on our local copies. And after my friend had made changes I simply merged them into my copy and cloned him a new copy.

hg merge
hg commit

So you can see that by keeping the projects away from a centralized server it limits the number of headaches that most version control systems create. I would highly suggest using a DVCS for any personal projects at first and then suggesting it to co-workers to use in a team environment. Depending on which DVCS you use will determine the learning curve but once you are familiar with one it will make your life so easy you will never want to go back to any other version control system.

Posted in General

Tags: Mercurial, Subversion

comments powered by Disqus