Mercurial has been my version and source control system of choice for some time. I migrated from using Subversion after using it for a project a long time ago with a couple of collaborators, and working with a distributed source made development a lot easier when we were all working on it at the same time from varying different sources. It’s not too different from Subversion, except for the obvious pushing and pulling from various repositories, and was pretty easy to pick up and get to grips with. Because I’d been using it for so long, I didn’t really understand where Git came from and always assumed it was harder to use and get to grips with than Mercurial, so I avoided it completely.
One of the benefits of Mercurial, so I thought, was that it was easy to get self-hosted repositories up and running, and I’d been privately hosting repositories on my VPS for some time, since I used to host Subversion ones on there too, I assumed this was something that was what everyone did. I had about 10 private repos stored on my server and developed on each one of them on-and-off on various machines, so having the central repository and multiple local clones meant even if I forgot to push from one machine, I could still get on with some development. What I didn’t realise I was missing out on was all the project management tools I really needed, such as issue tracking, wiki entries, commit tracking and so on. This is when I started looking for an alternative solution…
This is when I found Bitbucket, a project hosting service provided by Atlassian, that ran using Mercurial as it’s source control. This was the perfect setup, being able to manage my projects online using their tools, and delegating the responsibility of my repositories to a third-party service. Better yet, by this point, Bitbucket was completely free for unlimited private repos, so it really was the best choice. It gave me easily editable wikis, issue tracking, basically everything I needed.
Or so I thought. I did wonder if, by being a free service, Bitbucket’s support and stability was going to be lacking a little bit, since I knew it used to be a private service that charged. Turns out my fears were not completely unfounded. When trying to migrate all of my repositories over by creating new repositories on Bitbucket, something that should’ve taken a few seconds took a few hours. Of course, a support email later and a 24 hour wait and the problem was completely rectified, but I was a bit worried that I’d had to wait 24 hours, and that the problem happened in the first place, especially since the support staff quoted that “this happens sometimes, we just need to create them manually”. Dismissing a problem so casually tends not to be in my nature, so I tweeted in case anyone had any suggestions…
Migrating to Git
Of course, the first suggestion was moving to Git and trying out github. I was still a bit sceptical, but decided to give a go anyway, all I had to lose was a couple of hours in trying it out. It turned out there was a wonderful plugin for Mercurial, called hg-git, that would allow Mercurial repos to be pushed to Git servers, meaning I didn’t even have to lose any of my commits if I moved over! This cheered me up, and by creating a testing a couple of repos I found that Git wasn’t that hard to use at all, and was pretty much the same as Mercurial, with just a couple of subtle differences. By this time I’d signed up to github on their smallest paid-for package and started to migrate my most active repositories over, having no trouble at all.
I still compare github to Bitbucket, and I apologise for that, because they are completely different services, but it’s a natural habit. Github has very similar features to Bitbucket, such as wiki entries and issue-tracking, but the subtle differences make life a lot easier. For example, github has labels for issue tracking, which lets you create your own management for these problems, instead of relying on the priorities and constrained problem types like on Bitbucket. It also uses live-loading a lot more often in it’s interfaces, which means navigating the website is a lot quicker and simpler. I’ve even started using branches to keep track of changes more conveniently!
Git GUI Clients
MacHg had been my client of choice for Mercurial for a good while, and I didn’t fancy venturing back to the command-line for my day-to-day source control, I just can’t stomach it. So I needed a nice GUI to sit on my Macs for Git too.Git has it’s own GUI, gitk, which comes with it and runs in Tcl/Tk. I have never been a fan of Tcl/Tk, it looks like something from 1992, and only seems to fit in on minimal Linux desktops like Blackbox and the like, so I wasn’t going to put up with that on the Mac. Luckily, I don’t have to. Tower is a fantastic free GUI that, despite still being in the beta testing phase, feels very polished and very well thought out. The interface is superb, and the features, such as using Git’s stashing feature, and staging, link in wonderfully, so I’ll be happily sticking with it for a good long while. If you use Git with a Mac, I strongly urge you to give it a try, it’s a beautiful client.