26
May 11

VSS to Mercurial

Note: I was using VSS around 2 year back and move to mercurial when i have started my own company. Few days back I had discussion with one one of my ex colleague who is still using VSS and does not feel they required to move to new source control. This blog post is all about the discussion I had with him about VSS, distributed source control especially mercurial (because I am using it) and people who are not using any source control.

Why to use source control

Do you know “The Joel Test” – The first requirement of good software development is source control. If you or your company are not using it then change that; either company or way of work.

Now a days people don’t ask “do you use source control?”. They ask which all source controls you have used so far and what is your workflow.

Some people argue that I am alone developer and I take backup every night to my code (through some automated system or manual) and I don’t need source control complexity in my life. This project can be in your organization or your pet project in your free time.

My argument is; any serious source code should be in source control otherwise it is not serious. Backup is not primary reason to use source control it is a bi product of using source control.

Around two year back we used VSS as a source control. Its seems nice because I never used any other source control system. I heard about CVS, SVN etc but never get chance to using it. VSS had lots of problems like

  • It damage often. Once In past we even lose all the history from VSS due to damage.
  • Lock – VSS work on lock mechanism; where developer have to locked the file before start the work. So developer have to keep in mind before doing any changes with the code base. In locking mechanism no two developer can work on the same file at same time. There are lots of time when developer goes on leave and he locked couple of file in VSS.
  • Over internet VSS (Till the time i used) is not reliable. We use paid third party plugin to use VSS over the internet.
  • VSS required IT guy to manage the server.

When I have started in new organization, one of the first few things which I required is source control. My wish list for source control was

  • Free or less license fee
  • Reliable
  • Easy manageable (Till date we don;t have any server administrator guy.)
  • Work well on over the internet.
  • Good support on windows.
  • Reliable hosted solution.

I had couple of options a) SVN, b) Git (A big buzz word in source control due to github) c) mercurial.

All above are free and open source. github.com (for git) and bitbucket.org (for mercurial) was my favorite one because of distributed source control buzzword. After little bit of research I found that mercurial have better support on windows, bitbucket.org have option to create free account with private repository for life time and 5 users allowed with free account.

So I have decided to use mercurial because

Using distributed source control require only mental shift from client server source control system and that shift is really worth.

In distributed source control every developer holds complete repository on his local machine. so every time developer commit any change it commit on his local repository. Once he finish his changes then he push his changes to other repository. Because every developer holds copy of repository on his machine it gives following advantage.

  • Speed -It makes day to day task very speedy because it holds complete repository on his had drive and there are no network latency. He required network only for pull or push the changes form other repository. So It can be used online and offline. Distributed source control was design with the mind set that developer not necessary connected to internet/internet every time.
  • Separation of work by branching and merging - Branching is another reason to use mercurial. I never use SVN and there are no concept of branching in VSS. Consider the scenario- You and your team have just release the code base to QA and then you have start working on future version of app and same time QA is raising bugs. I don’t know about the SVN but in VSS handling these type of situation is not possible. In VSS days we all are not allowed to write new code until QA have finished all the testing and there are no more bugs. Once everything is fixed we label the codebase in VSS and start working on new version. In mercurial we create new branch and start working on new version with other team mates. If QA raised any bug we simply switch to main branch and fix the bugs. Once QA done with testing we marge newly created branch with main branch. Switching between branch in mercurial is super easy and pain less.
  • Reliability – Due to distributed nature it really hard to destroy. As each developer machine have complete repository creating new centerlize repository is pretty easy.
  • Easy to learn – I have started using mercurial after 2 hour of learning.
  • Collaborative – Distributed source control allows developer to communicate directly without affecting the central server.

Only mental shift you require while working with team in organization is; you need to have one centralize repository. Every team member will pull or push changes from centralize repository when they are ready to. It don’t mean that you can’t pull or push changes with your team mate. Centralize repository will don’t have working directory because nobody will going to work on centralize server. Every team member will only push his latest finish changes to centralize server and take latest changes from centralize server. Just as we do with VSS or SVN . So distributed source control have all the advantage as client/server source control with addition to speed, reliability and high level of celebration with other team mate without affecting the central server.

Our setup

We have pretty simple setup. Every developer machine have configured a free account of dropbox (2 GB is so far sufficient for source code backup). We use bitbucket.org as a central repository. Every developer have it own repository and working directory in dropbox folder.

Resource

I have used http://hgbook.red-bean.com/ for mercurial.

http://hginit.com/ is also a nice tutorial about mercurial and distributed source control.