Daniel Hoelbling-Inzko talks about programming

Moving to Mercurial

Posted by Daniel Hölbling on May 30, 2009

I feel like I’m constantly falling behind on stuff I want to post about but don’t get around to. One of which is the version control system Mercurial I have been using now for almost 4 months and loving ever since.
Since Google just decided to enable Mercurial on Google Code I figured it’s a great time to write about it.

What is Mercurial?
I’ll quote the getting started article from Bitbucket:


Mercurial is a distributed version control system, or DVCS for short. It is in the ranks of Git and Bazaar, leading a new paradigm of working with version control.


This new paradigm of distributed versioning allows for several things that centralized development does not. Specifically, it provides:

  1. Allows commits/logs even when working offline
  2. Drastic increase in speed for most operations
  3. Ability for anyone to have their own copy of a project, and continue work without explicit "commit access"
  4. No requirement to publish changes
  5. No need to set up a server for version controlling things (self-contained)

So, it’s like your  own private version control system. Nobody can mess with it, you own it.
Which is great, I mean: How often has a fellow coworker submitted something to your tree that made your code break? Or how often did you update before a commit just to see that the update breaks something (and your changes weren’t commited, so you’re at the mercy of merges)?

What also rocks is it’s simplicity. Mercurial needs no server, so even on my little pet projects I can leverage the power of a SCM system without the headache around setting up something in a central place.

What most people though fail to understand is that the centralized model does also mean that you need to share your private changes with the world at some time.
And while doing so on a shared filesystem is very easy (when sharing with a coworker for example), doing so over the wire is non-trivial as it would require you setting up a server somewhere.

And that’s how I learned to love Bitbucket:

Bitbucket's aim is to compensate for this while maintaining the flexibility and benefits of DVCS. It does this firstly by providing a centralized location for a repository which provides a sharing-point for one or more developers to grow their code base. Secondly, it provides a set of tools that ease development and sharing of a code with the rest of the world.

Bitbucket is free and gives you 150mb of disk space, an issue tracker and a wiki for each of your projects. While the limitation is that only one project/repository per account can be private (not open source), there is no limit on how many public repositories you can create.

I suggest reading the guides on Bitbucket (or the book) on how HG differs from SVN and how the usual workflow looks like.
Also I suggest installing TortoiseHg, this will install all the hg command-line as well as a nice shell integrated GUI like we are all used to from TortoiseSVN.

Filed under programmierung, subversion
comments powered by Disqus

My Photography business


dynamic css for .NET