Clear message

The first Mercurial user survey

BryanOSullivan [http://www.selenic.com/pipermail/mercurial/2006-April/007513.html announced a user survey] in mid-April 2006. On April 26, he collated the results and posted them.

TableOfContents()

Who responded

We received 63 responses, from 20 countries.

As is usually the case with surveys, we don't know how many users Mercurial really has, or what the response rate was.

Where users live

57 of 63 respondents (90%) answered.

Getting started

How people found out about Mercurial

56 of 63 respondents (88%) answered.

Interesting quotes:

• I work for a small company, and we were told that we needed to be SAS-70 compliant. This brought a lot of grief to the develpment team, since we realized that our current (svn) code handling was not up to par. This started our search, which came back pretty dry. Mercurial seemed to allow us to do many of the things we were hoping to be able to do with our source code.

• Ollivier Robert's [http://www.keltia.net/EuroBSDCon/paper.pdf paper on using Mercurial for FreeBSD development].

• I have to admit that I was lucky enough to attend a presentation by Matt at the OLS. Though the presentation was short (around an hour), it was more than enough to get me into it.

Was Mercurial easy to learn?

56 of 63 respondents (88%) answered.

Interesting quotes:

• Core concepts are very simple and you don't have to deal with something like darcs' "theory of patches".

• I've always thought that examples are the most helpful when it comes to learning an SCM
• I was up and ready to go with Mercurial in less than 5 minutes and even if my use of it was sometimes sporadic, it was always trivial to get back into it.
• Quite easy to use, a bit tricky to understand fully.
• Mercurial was extraordinarily easy to learn.

What was most helpful in learning to use Mercurial?

45 of 63 respondents (71%) answered.

Interesting quotes:

• It definitely helped to start using it for versioning my home directory

(or parts of it) and have it replicated across multiple machines.

• I wish there were more wiki tutorials, dealing with some of the more complex scenarios. I do an update -m, I screw up the merge (which I seem to do often), now what do I do to recover? What is the point of "update" without "-m"?
• I found the different switches to hg update especially confusing at first. Extensions are sparsely documented and I still can't master the regexes/globs/whatever on .hgignore and similar.
• The basics are easy, it's a bit more complicated for more advanced stuff and for new undocumented features.
• Basic usage was very easy, but setting up a server with multiple users and repositories, and actually using the distributedness is more complicated.
• By far, the most useful tool in learning what's going on is "hg view".
• The fact that the command-line syntax is similar to Subversion or CVS definitely helps.

How people use Mercurial

What do people use Mercurial for?

54 of 63 respondents (85%) answered.

Interesting quotes:

• I like Mercurial so much that I even use it when developing patches against projects still using things like CVS (thanks to [http://www.darcs.net/DarcsWiki/Tailor Tailor]).

How do people obtain Mercurial?

56 of 63 respondents (88%) answered.

Interesting quotes:

• Distributions' packages lag too far behind.

What systems do people use?

56 of 63 respondents (88%) answered.

How many people do users collaborate with?

48 of 63 respondents (76%) answered.

Interesting quotes:

• hg serve is incredibly useful for short hacking sessions with another person

What sizes of repositories do people work in?

50 of 63 respondents (79%) answered.

|| 33 || 10-100mb || || 13 || 1-10mb || || 8 || 0.1-1gb ||

|| 2 || 1-10gb || || 1 || 10-100gb ||

How many projects do people use Mercurial with?

52 of 63 respondents (82%) answered.

Which extensions do people use?

47 of 63 respondents (74%) answered.

Interesting quotes:

• mq is not well enough documented.

What do people think of Mercurial?

How happy are people with Mercurial?

56 of 63 respondents (88%) answered.

Note: the original question didn't ask for a numeric score, so these values are approximations based on the levels of enthusiasm expressed.

Interesting quotes:

• I consider Mercurial the best version control system on earth. (Not the most stable one, but the most versatile and user-friendly one.)
• i would say that Mercurial needs a lot more work in terms of becoming stable and polishing up
• Satisfied on Linux, but Windows version is a bit buggy. For example, "hg status ." doesn't seem to work in WinXP.
• I actually keep comparing bzr with hg, waiting for bzr to become as mature, robust, stable and fast as hg, but they still have a long way to go.

What other SCMs did people mention?

How does Mercurial compare to other SCMs?

53 of 63 respondents (84%) answered.

Interesting quotes:

• general
  • It's very light weight in terms of infrastructure requirements to host a repository (like CVS) yet it is full-featured.
  • Mercurial is so much better because it does not annoy the user. Mercurial does the advertised work, and that's it. I like the KISS philosophy of Mercurial.
  • It still lacks good support for the end users (ie. no guis).
  • The model for what a version is and how it relates to other versions is clear and understandable.
  • I like the flexibility of being able to do different types of collaboration (besides just client-server) all with the same tool.
• bzr
  • I tried out bzr but didn't like it, it's becoming conceptually too complex.
  • Less conservative than monotone, and still more focused than git and bzr, which seem to grow features without end.
• darcs
  • I've converted from darcs just because of the speed, but now I'm hooked.
  • Scales great, but I much prefer darcs in every other respect.
• git
  • git/cogito has a totally broken user interface, and the git-repack and git-fsck-objects thing sucks
  • I like how git manages branches inside the same repo. I know hg can do it but it's awkward; using a tag to identify the branch is not really useful.
  • Not a bunch of languages like GIT is.
  • Git seems to have more features and has a more active community. It advances faster than Mercurial, it has corrected the few defects of its early versions.
• monotone
  • Chose Monotone, got confused, switched to Mercurial.
  • Monotone is simply too slow to use, even on smallish trees on my dual amd64.

  • I think the monotone manual is about the best SCM doc I've seen (not that it really covers the inevitable problems either), but note that I'm assuming it was the monotone *model*, not the docs, that confused me so much that I ultimately rejected it!

• svn and cvs
  • Beats the crap out of Subversion, in my opinion.
  • Disadvantage to Subversion no graphical version and extra tools.
  • I find it *much* less confounding than SVN. I mean, honestly, it took me all of 5 minutes to get the cgi web presence up?
  • We recently did a brief evaluation between SVN and HG in our team and SVN won.
  • I used to like CVS a lot. I can't imagine going back. Really.
  • HG is vastly more flexible than CVS, and much more forgiving.

What do people like most about Mercurial?

54 of 63 respondents (85%) answered.

Interesting quotes:

• The functionality/complexity ratio is astoundingly high.
• The developers are super-helpful.
• HTTP based pull is great since it works through nervous firewalls.
• Working copies and repositories are the same thing; this allows for great flexibility.
• The community is great around Mercurial.
• Improbably fast for something written in Python.
• Its ability to scale with the users' learning of it.
• Very reactive development team.
• It's possible to 'guess' commands or workflows.
• The push/pull concept, combined with the cheap cloning, makes cooperation with other developers (or myself) trivial.
• Mercurial's conceptual model is clean and simple enough to carry around

in my head.

• Simplicity and easy for my use, but I know it can scale.

What would people most like to see improved?

55 of 63 respondents (87%) answered.

Interesting quotes:

• Publish version 1.0!
• If mercurial development would grind to a halt right now we'd have a fine product still.
• A clearer way, at hgweb, to allow full tree download as a tarball. It would be nice to have it at the fist page for each project, on a button or something clear.
• Most people around here like CVS's "recursive from here down" behavior better than "repository wide by default" behavior of hg.
• metadata in patches (copy, rename, mode change, ...)
• hgk needs to take some arguments to limit the amount of changesets displayed (like gitk does)
• hgweb miss one interesting feature, imho: I really want to separate the

public repositories from the user ones. However, I cannot see how can I do it with current struct

• remove unbundle (use pull instead)
• I always get annoyed by the fact I cannot just copy/pase a path name from a "hg status" to a "hg diff"
• Much improved, not similar sounding, verbs (undo/revert/remove/backout etc.)
• ability to use pull, push or unbundle in combination with the gpg extension to ensure that only changesets that had been signed by a key in some particular set were added
• Merges requiring manual fixups can be confusing. If I have uncommitted changes, pull, merge, and then commit, have I just committed my changes as well as the merge? Also, I believe 'hg diff' shows both sets of changes in this situation.
• Annoucements in the style of Junio Hamano's "What's in git.git" would be nice.