We are making the switch to Mercurial for our source code control.
The last year or two has passed by and everyone has been talking a lot about git and tons of developers are using github.com. At first, I was thinking it was a fad. Then more time passes and it becomes clear the fad had passed as it turns out we were missing out on how great Distributed Version Control Systems are; which git is one of them.
Instead of jumping in and assuming git was the only way to go, I wanted to better understand Mercurial too. Mercurial is often mentioned when compared to git and I just stumbled on it when looking at how to host git repositories. Many people I have talked with haven’t even heard of Mercurial; in part because Mercurial doesn’t have github.com and its not marketed much. After plenty of time with both of them we are moving from Subversion to Mercurial.
Since our previous blog posting on how to host a private mercurial repository on Mac OSX, many asked “well why Mercurial?” or “I just started using Git and I thought that was cool?” There are tons of comments on stackoverflow.com or blogs about why git or mercurial is better than the other(this being my favorite); Google even did a nice write up the subject.. I thought we’d add to discussion and how it fits better for us.
All the power of DVCS
Just like Git, Bazar and a few others Mercurial gives you all the power of a distributed version control system. You probably already know why DVCS is awesome, if not go look into it. The following few paragraphs can be accomplished in the other DVCS’s, so this section isn’t totally specific to Mercurial.
With Subversion we worked very linearly. Like many teams, of commits done in /trunk. We rarely made branches, because it was too much of pain to merge back and most of the time it didn’t work right. So there was too much over head. However, as last progressed we began collaborating on code a lot more. Making it very tough to be a linear programmer. Also we tend to move from laptop to desktop a lot; backing up code in /trunk was stupid… but we did it.
With Mercurial we can easily make a branch…
# hg branch new-branch
done. Now all the code I work on is in a its own branch, until I merge it back.
To move from one computer to another we can either check in that branch to the central repository, or clone it from the computer we are moving from.
macbook pro – # hg serve
mac pro – # hg clone http://macbook.pro:4000
done. Now that code is on my Macbook pro, since I moved from my Mac Pro.
Those are the biggest problems we have been having. Now it is very common for me to have a seperate branch for every ticket in our issue tracker. Then merge it back into our default (or a dev) branch when its complete. Those branches are commonly in the repo and deleted when no longer needed.
Private Hosting
One thing important to us is to host our code ourselves. We have the hardware, the bandwidth and server admin (Hasani) to handle it all. Not to mention we have a pretty nice system setup for backups, authentication, issue tracking and continuous integration that it would have to be really awesome to switch to something else. Hosting it ourselves, we wanted to be able to host over https and not ssh.
Mercurial makes it plain easy to host over https. Locally you can run hg serve and that starts a web server on your local repository. To take that a step further you can use any web server and a CGI script that knows about the other repos; I wrote a blog post on doing that a few days ago.
When you want to host git yourself the answer was: just use ssh or just use github.com. That wasn’t good enough for me.
Also I should note that BitBucket.org is a Mercurial version of Github.com (for lack of better descriptions). As of the writing of this blog post, any use can have an unlimited amount of private repositories hosted by them. If you prefer to use something like that.
Mercurial doesn’t make you feel stupid
Its understood that git has a learning curve. Maybe I haven’t used it long enough, but I thought after a few weeks with the command line it wouldn’t make me feel so stupid. Too often there was warnings, errors, messages that confused me. Mercurial is a single command and all the sub-commands were pretty easy to remember; including their option flags.
Maybe it’s because I am coming from subversion and much of those commands were very similar. Or maybe its because the articles I read at the time were more clear on what to do. Or maybe its just me. Who knows. But Mercurial was just easier to use from start to the advanced operations.
As we have begun switching our source from subversion, having similar commands has made the transition much quicker/smoother.
History is preserved in Mercurial
In Mercurial you can’t change previous committed code. In git you can change the past commits in the repo. I am sure there are cases where the linux kernel needs to do this (I can’t think of any), but this is some we don’t even want to have the option to do.
Branches stay with the Repo
This is something we like a lot. When you create a named branch in Mercurial, you then commit it to the repo. That named branch is generally sent to the central repo (or other repo if you have others). To contrast with git, you create a branch then sent optionally sent it wherever you want to. Most organized teams find this no problem. We however, prefer to know and track all branches created through the repo.
Super easy to convert from Subversion
Setup hgsubversion
# hg clone https://SVN-REPO.COM/repo/path
done. You can also use the hg convert command to convert subversion to mercurial. I converted a ton of our repos to mercurial in less than an hour. It maintained all tags, branches, commit logs and authors.
Summary
We’re loving Mercurial. The only problem we’ve had with it is the lack of good documentation, blogs, etc. Much of it is older and needs updating or needs better marketing. So we’ll do our best to document what we done, found, etc as the months progress. I think more people need to know about it.
Related posts:
I hope you all find it clear that we spent time with both DVCs: Git and Mercurial (hg). We wanted to be sure we found the best tool that fit us. As it turns out it wasn’t Git, contrary to how much people use it and all the press of it… we felt hg fit us better. Namely because of the http hosting, learning curve, conversation and migration process.
Private hosting was a big deal to us. Just using GitHub wasn’t something we wanted to do. We have the hardware, why rely on something like Github? Hosting with hg is simple.
You get all the same power, with very little learning in a package that just felt more sound. Everyone has their own opinion too… we understand. That’s why I wrote this up.
Actually HG has its own learning curve, you just didn’t start using its features yet. I find branching in mercurial cumbersome so I end up not cutting branches but making multiple clones (which is the old way of making branches in mercurial). Also if you are an advanced mercurial user, you would know that you can indeed delete history with mercurial.
You talk about “deleting” Mercurial branches, but I wasn’t
aware that is easily done. Perhaps you’re referring to the ability
to close a named branch, which essentially hides it from
view?
This excellent tutorial by Joel Spolsky got me started on
version control in general, and served as a perfect introduction
not just to the powers of DVCS but Mercurial in particular.
http://hginit.com/
There are a lot of great reasons for hg, but “Mercurial is
The options flood – I hear you on that. git help is my best
until you’ve rebased your repository
a single command” is not really one. (Especially since git is, too.
friend since I started using it, and I can’t see that going away
any time soon. Oh, and a built-in server is part of git, too.
(git-daemon) “History is preserved”, however, is the big one. You
haven’t used git (or lived
to hell – and unfortunately, you can force-push that to the master
server. So you *might* want to highlight a bit more
As someone who prefers to use Mercurial but has to work with Git from time to time, I have been burnt by the hg branch management tools. There is no easy way to delete dead branches (ie, you decide to create a v2 branch only to then later abandon it. Going back to the default branch and merging with other users is going to be a problem with the dead v2 branch hanging around.) If mercurial just let you delete a branch that would be cool but counter to the historical accuracy of a repository.
If you’re nervous/unsure about branches being in the permanent record of your repository you should use clones for ‘branchy’ development workflows.
If you’ve made a mistake with a branch there’s a wiki page dedicated to pruning them: http://mercurial.selenic.com/wiki/PruningDeadBranches
This is one of the mercurial quirks that all my associates who use git like to remind me of.
There’s a great article about the differing philosophies of
Git and Mercurial call called “Git vs. Mercurial: Please Relax” at
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/.
Great that hg is getting some well-deserved recognition.
There’s also “The Real Difference Between Mercurial and
Git” at
http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/
For hosting your own git repo, see gitolite. Although it
isn’t over http so maybe of no interest to you.
@Justin, Yeah I did not mean physically deleting branches, I meant that branches are closed and no longer viewable. Wrong word.
@Huy Do,
I setup a few of the hosting options in Git (including gitolite). They were okay, but all ran on non-standard ports and we wanted it all to be on https. Mercurial was plain simple to get it setup properly on our servers for our continuous integration, bug tracker, etc to all play nice. Being over https is ideal, since we work remotely so often. Lots of places we’ve been at have blocked non-standard ports and we don’t want to be stuck; even if we have most of the repo locally on our laptops.
@Al Willis
Great links. I had read that please relax and a few others many times. I guess I missed the big holy war from 2008. Ultimately we didn’t want to pick git simply because everyone else is; pick and switch based on us, the way we work, and the way we have our systems setup.
I intended this article/post to be a simple approach to selection; and not super technical. Where a lot of articles out there were focused on the technical differences. Since most of what is technical between the two is already been written. Hosting challenges, simpler switching, simpler conversion, and other more subjective items haven’t been talked much about.
@Rachel,
The built in server in git was not helpful for us. Sure you can run it locally and get the same out of hg serve (even though I found hg serve to be tons better). The big thing was setting up the hosting via Apache with authentication over https. Doing so in git was not really an option.
I see your point with git is a single line command too. I guess I worded it wrong. Basically I was getting at the commands were far more sensible than git. In git most times I was adding a bunch – to do anything. That’s why I felt stupid with it. Like you I ended up using git help way too much to get work done. That wasn’t very pragmatic to me.
hg won out because it was the most flexible for us to host, simple transition from svn for us, all the same great dvcs goodness, fits into our environment great (of CI, issue tracking, backup, etc), converts subversion repos excellently and we were up coding and working in the repos efficiently very quickly.
@Huy Do,
Gitolite can do http also…
But mercurial have RhodeCode, that really is a something like self hosted bitbucket
@notnotOR, you have just blown my mind. Rhode Code looks like just the thing we need. We will give it a go and let you know what we think. I don’t know how I never found out about it until now. It sure looks like it gives BitBucket and Kiln a run for its money. At first glance, I love the UI.
Thanks again.
-Andy
Great post thank you Andy, I was also evaluating both Git and Mercurial and it is a hard decision but I agree with all the points you mentioned in your post and I think I will also use Mercurial.
In your post you mentioned that you use CGI to host on Apache, I recommend you try mod_wsgi (if you haven’t already) which is much easier to setup and faster than CGI and the recommended method for hosting Python on Apache, here is a quick tutorial http://mercurial.selenic.com/wiki/modwsgi
Good to know about mod_wsgi. Thanks!
While I still hold true to all my statements on mercurial side in this post, recently we have made the jump to git. You can read more about the process and some of my thoughts here. Once you get in a good groove with mercurial, I suggest checking out git. If for anything reason to validate working more with Mercurial. Which ever you choose or change to, etc…. DVCS is the way to go.