Mercurial

General introduction

Mercurial is what you call a distributed version management system. That means, you have a local copy of the repository (including the full history). In contrast, svn only has a single copy on the server.

In that sense, mercurial is very similar to the other new generation version management systems as git or bazaar. I mainly want to motivate here to use a distributed system, which one is just a matter of taste. Mercurial is still relativley simple and, in contrast to git, has all the dangerous features disabled by default (e.g. rebase)

Coming from svn, it's definitively worth to read: http://hginit.com/00.html

Why to use mercurial

You might say svn works so well, why should i switch to something which - at the first look - seems to be more complicated. Again, read http://hginit.com/00.html. Let me just mention a few points:

• you can do many commits while working on a feature without pusing to the server and possibly breaking the build
• very powerful branching / merging functionality (svn can do branching, but see comment below). This is very important as soon as more people start working on a shared feature.
• by that doing reverts and saving steps whenever you want
• having a local copy of the repository allows you to work offline, and do commits without an internet connection
• local access to history is very fast

About branching and merging, you might say svn can to that. But take your time and read through http://hginit.com/00.html Let me extract one comment which i think exactly gets the point:

“The trouble with distributed version control is that it makes it too easy to branch,” I said, “and branching always causes problems.” Turns out this was wrong, too. I was on a streak. Branching causes problems in Subversion because Subversion doesn’t store enough information to make merging work. In Mercurial, merging is painless and easy, and so branching is commonplace and harmless.

Also good

Since all new code that you write has bugs, you have a choice. 1) You can check in buggy code and drive everyone else crazy, or 2) You can avoid checking it in until it’s fully debugged.

Subversion always gives you this horrible dilemma. Either the repository is full of bugs because it includes new code that was just written, or new code that was just written is not in the repository.

Advanced

Working with svn

Mercurial can be used to work on svn repositories, however, there are some drawbacks on branching I'll mention later on. Let's start with the basic stuff.

An easy way to interact with an svn server is to use hgsubversion [1]. What I'll write here is mainly taken from the first part of http://mercurial.selenic.com/wiki/WorkingWithSubversion

One big problem is that svn uses a flat history which forbids all the advanced branching functionality. I found it useful to use the proxy repository concept, see section below.

From svn to mercurial

To get the initial clone of the svn type (WARNING: this step can take very long since it parses the whole history)

 hg clone svn+http://.... <localfolder>

To get changes from svn, just use hg pull as you would normally do

Pushing to svn

You can use hg to push to svn by just doing

 hg push

This is a simple, but not so powerful way, please read on the next section.

Working with a proxy repository

WARNING: what I describe here sounds horrible, but is very usefule. It would become obsolate if we would switch to a hg server.

Using the simple direct way described above, one looses a lot of the benefits that come from mercurial. That is for example being able to do many local commmits where you don't have to care about proper commit messages which are obligatory in our group. Again, svn could in principle do branching, it just does merges not very well (see introduction).

TO be continued;