Earlier this week, Bitbucket announced its plan for killing Mercurial support by next year.
This doesn’t come as a shock to anybody who has been a Bitbucket/Mercurial user, since Atlassian’s investment in Mercurial had been declining for the past few years. So I think their reasons for taking this decision are a bit ironic in addition to being shortsighted:
Building quality features requires intense focus, and supporting two version control systems means splitting focus – doubling shipping time and technical overhead.
The cat was never really in the bag, since all the conversations around this, and the code written for it, were all publicly availble on sr.ht’s code hosting, developer mailing list, and IRC channel (#srht on Freenode), but I’m happy to, at last, officially say that I’ve been working on sourcehut for the past few months, adding support for Mercurial hosting.
You can find all the relevant details in Drew DeVault’s annoucement (Drew is the principal developer on sourcehut).
Edit: since the original publication, I added a paragraph on vim-signify and a few other little tips based on some #mercurial IRC feedback.
I already mentioned Vimways’ advent blogging about Vim, but here’s some more commentary on one of their entry, namely the Vim and Git one. It was quite good so I figured I would write a “Vim and Mercurial” one!
Since Samuel (the original post’s author) did a good job with the overall article structure, I’m going to totally plagiarize it.
Here’s another advent blog series! This time it’s from Kamal Marhubi and it’s on the subject of Mercurial. It’s pretty interesting, especially for giving a fresh perspective on Mercurial’s user experience.
The introduction post lays down some of what makes Mercurial interesting (phases, changeset evolution, extensibility) while the third post catches up to another cool thing (revsets, one of my favourite Mercurial features) that was missing from that initial list.
I recently came across Josef Sipek’s series of articles on setting up a “modern Mercurial”. In the first post, he realizes that he was missing out on a lot of the new features that had been added to our beloved hg along the years, due to the maintainers’ policy of not changing the default CLI behaviour.
I realized I had the opposite problem – my .hgrc is a loose collection of snippets I gathered from all around the web, at various times, and as such it has accumulated several layers of Mercurial history.
If you’re using Mercurial with mixed sub-repositories (i.e. sub-repositories handled by different revision control systems), you may be interested in this: I just got a patch accepted into the onsub extension.
The extension lets you run commands on your sub-repositories. For example, with my own dotfiles repository, running on Windows:
> hg onsub "echo I'm in %HG_SUBPATH%" I'm in lib\hg\hg-git I'm in lib\hg\onsub I'm in vim\bundle\badwolf I'm in vim/bundle/colorschemes I'm in vim/bundle/commentary I'm in vim/bundle/ctrlp I'm in vim/bundle/easymotion I'm in vim/bundle/fugitive I'm in vim\bundle\gundo I'm in vim/bundle/haml I'm in vim\bundle\lawrencium I'm in vim/bundle/markdown I'm in vim/bundle/nerdtree I'm in vim\bundle\piecrust I'm in vim/bundle/powerline I'm in vim/bundle/ragtag I'm in vim/bundle/repeat I'm in vim/bundle/solarized I'm in vim/bundle/supertab I'm in vim/bundle/surround I'm in vim/bundle/syntastic I'm in vim/bundle/vimroom As you can see, I’ve got quite a few sub-repos.
These days, all the cool hipster kids want to deploy stuff by pushing a Git or Mercurial repository up to their server.
And that’s pretty cool indeed, because you basically update your website by doing something like:
hg push myserver So here’s how you can do it with PieCrust (although 90% of this article has nothing to do with PieCrust):
Installing Git/Mercurial/whatever on your server Setting up your SSH keys Pushing your repository Defining hooks/triggers Keep reading for the meaty details…