Skip to content

Shortcomings of Mercurial

Mercurial is, by far, the best revision control application I’ve ever used, with Git a close second. Fundamentally, Mercurial does revision control correctly: distributed, clean CLI, and good documentation. I’ve never had any qualms with it, even in team settings. On the other hand, I have noted some complaints teammates have had with Mercurial, sometimes complaints causing them to stop using Mercurial or DRCSs all together.

  1. Mercurial doesn’t maintain file and folder permissions. This becomes a problem when hosting a shared Hg repository on a machine without root access. Other group members add files to the shared repo via ssh and it’s up to the users umask to set file permissions. This means I may have files in my home directory which I can’t access.1
  2. Merging tools and file servers on Windows are lacking. Windows users expect the revision control to supply these tools. Unix users (including Mac OS X) are used to having file servers and merge tools supplied by the distribution of the operating system, not the revision control application. Some Windows users want GUIs like TortoiseSVN.2
  3. Binaries are handled terribly. Mercurial currently doesn’t good way to handle binaries. For instance, if a binary (such as an image) is moved, it’s considered a new binary. Keeping many binaries in revision control and moving them a lot will make the repo huge.

Aside from binary handling issue, I think the reason these “shortcomings” have never bothered me before is because I consider the file permissions to be a part of the operating system and the merge and server tools to be separate applications. Mercurial, thought easier to use with said external tool, is just as functional without and I will continue to use it as my main development tool.

← Previous Post · "Revision Control" Series
  1. When I asked about the file permission problems on the Mercurial mailing list, the Mercurial maintainer responded with this:

    Patches to inherit permissions from “.hg” are now in the crew repo which
    will get merged into mainline shortly and show up in the 1.0 release
    very soon.

    In the meantime, you’ll have to beat people into setting their umask
    properly.
    — Matt Mackall

    [↩]

  2. TortoiseHg is now available for Mercurial. [↩]
    None Found
  • Better rename handling is currently being worked on in Google Summer of Code 2009: http://socghop.appspot.com/student_project/show...
  • Jakub Narebski
    Git pack files uses binary xdiff for deltaifying, so having many large binary files and moving them around shouldn't be the problem. On the other hand Git does not track renames, but does similarity estimate based rename detection, so if representation of binaries changes much (e.g. encrypted files) you are out of luck...
  • Jakub Narebski
    Ooops... sorry for repeating myself.
  • For a GUI, you'll want to use TortoiseHg. By the way, your blog doesn't seem to put dates on your postings, so I've no idea whether you wrote this yesterday or a year ago.
  • So now that 1.0 has been released, I haven't checked but I'm assuming the file permissions problem has been fixed. And TortoiseHg solves the GUI problem for Windows users. But what about the way binaries are handled? Especially if my group loves to move and rename binaries in revision control? This, in my mind, is the final hurtle for Hg being used without hesitation.
  • It's over there on the right, but it took me a while to find it too, and it would be much better if it was nearer the title of the post.
  • Yeah sorry about that. I didn't design the theme but I have to say, for most cases I'd prefer it over there on the side. I respect the designer and his design decisions.
  • I have never really used Hg, but when I read the issues you point out, I wonder what makes it better than svn.
  • This article has links to the videos that showed me why DRVSs are better. Let me know if you still don't see after reading that article.
  • Jason
    TortoiseSVN uses should check out TortoiseHg (http://tortoisehg.sourceforge.net/)
blog comments powered by Disqus