Branching in Mercurial

Branching is a great feature and is used extensively when you work with modern DVCS (as in those, merging simply works). When I still used to use SVN in our small teams (3-5 people) we never branched as that would just mean too much work-overhead with the merging process. Instead we all worked together in an office, each one of us had his files he was responsible for, and if someone else needed to change something in them, we communicated! Manually merging conflicts was hell, and in SVN merging mostly boiled down to manually merging conflicts.

Then I met Mercurial and I deeply fell in love with it. It could have as well been Git, Mercurial was just lucky there to meet me first (though after having worked a lot with Git as well as Mercurial now, I’d say, Mercurial has a leaner approach, simpler and shorter commands and is therefore nicer to work with). I really had to use Git when I started working as Ruby/Rails developer in 2011 and with that work branching came naturally along. Git has a sophisticated branching feature allowing you to have your own local branches alongside global branches (called remote branches), or to just pull branches you are interested in, showing you wich branches are merged into other branches, saving you from deleting branches that haven’t been merged yet, rebasing instead of merging to get a cleaner log, etc.

And Mercurial? Well I know that branching does exist, and I also know that there’s even another funny way, with bookmarks. You always read about them, when looking into books and tutorials about Mercurial. I also remembered reading something strange on the official docs of Mercurial (I guess, but I cannot really find it now), which suggests to use clones instead of branches. On my first day with Git I considered this a good practice – then I was shown what branches are πŸ˜‰

Still if you’d ask me (like someone recently did), I couldn’t answer you how branches work in Mercurial as I never used it. I just know that it uses a much easier approach which is fine for most but may not be as sufficient for you as Git’s branching implementation – at least that’s the word on the street. Now the funny part is, that I have like five-ish repositories on GitHub using git, and just recently cleaned up my Bitbucket account reducing my fifty-ish repositories to 34. Yes, when working privately or in small teams on really small projects (e.g. at university we’d have to hand in any homework as a team of two, so we divide up the work and simultaneously work on a TeX file) I prefer Mercurial over git. I guess I’d also prefer it for bigger projects or larger teams, but untill now the majority always wanted to use git (or it already was a Git-Project long before I came along).

Not really knowing about how branching in Mercurial is done and how it differs from bookmarks somewhat bothered me, and when yesterday (actually, I’m like talking about that yesterday from like two or three days ago) I found out that Atlassian (developer and host of Bitbucket) integrated a (really) lightweight version of their (in my opinion really sophisticated) issue tracker (and project manager – but they didn’t really include that to the lightweight version) JIRA and after exploring those features I finally took a look at how Mercurial does it, and how this is differing from what git does.

While researching I came across a really excellent summary of everything possible in Mercurial and the appropriate pendant in Git, written by Steve Losh, titled A Guide to Branching in Mercurial. If you never heard of branches and ask yourself why and how you should use them, I also found a Stack Overflow post that could show you the advantage (and it’s nearly exactly the way we use branches at work, except that we don’t have release versions. But each issue becomes a new development branch and when finished they are merged into a testing branch, and only after testing the features will they be merged into the master branch). To put it simple, branching allows you to separate your concerns, and to enable people to work on different issues in parallel while not changing or touching running code. There’s another great blog entry by Steve Losh, Mercurial Workflows: Stable & Default, which gives you a workflow you could use when developing. It’s an easy to use and to understand workflow consisting of two branches (though for the given reasons I’d actually like the other way round better – i.e. a master/default branch next to a development branch).

Actually, I was pretty impressed by all the answers that I found by Steve Losh, that I spent some more time on his page. And while doing so, I stumbled upon his side project called hg tip (and if you find it easier to read in German, there’s a German mirror of the site). Finally a clone from the really perfect site git ready. If you’re ever forced to work with Git, git ready is the best resources on the entire net, whenever you’d like to do something that is a little out of the ordinary. For me it is the goto page whenever I work on a Git repository (sometimes I even open the page before I stumble upon any problems – just to have it ready in a tab – just in case πŸ˜‰ ).

Now when it comes to hg tip, the site is still far from having the extent that git ready has. If you’d spend an hour you’ll have read everything and incorporated anything you found interesting. Never the less, the site is hopefully growing, and it really has some really nice tips. I guess my .hgrc just grew about 50% after having found the site πŸ˜‰ (Btw. I just recently lost a dotfile in one of my many backups, so I finally started uploading them to a public repository on my Bitbucket account. Just in case you’re interested).

But again, I digress.

When it comes to branches in Mercurial I never really needed them. Then again, when does the point come, where you need branches and will you recognize it? Isn’t a clean and neat start from the beginning important? And doesn’t that include some kind of release management – even if it is something that you’re just hacking stuff together and that’sΒ intended just for personal usage?

How do you handle this? Do you make use of your favorite DVCS’ branching capabilities for all of your projects? Or do you consider it too much overhead? When comes the point where you decide that now you’ll need branching? Obviously I’m not talking about team work, as there on should probably work with branches whenever you work in a team. But what about your single-person projects? If you do make use of branches for single-person projects: How do you do it? stable/development? Branch for every new feature? Branch for every major release version? Some totally different setup? Please comment πŸ™‚

I for now will try using branches for all my projects, which aren’t that many anymore (a huge bunch is falling away since I’m finishing my Bachelor studies). I think in general it is a good practice. I also know that I’ll probably won’t keep it up for long (at least if I don’t manage to make it a habit), but as long as I don’t have to say “Well I actually don’t know about branching in Mercurial” after praising Mercurial and ranting about Git, my efforts will have served a purpose. I guess what I really like to do, is to have two main branches, maybe additional feature branches, but I guess it wouldn’t make any sense as I wont be working on different features at once. When it comes to release versions, I guess I’ll give tags a try and won’t have a branch for every release – but I fear it’ll take some time till I’ll work on one of my major projects again, so untill then no experimenting with different release versions 😦


Please comment. I really enjoy your thoughts!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s