UserSurvey

BryanOSullivan announced a user survey in mid-April 2006. On April 26, he compiled the results and posted them. Thanks to everyone who participated!

For a short-form report that contains the conclusions drawn from this report, please see UserSurveyConclusions.

About this report

This is a detailed summary of all of the responses we received. Where appropriate, we present tables of numeric responses. We also provide a representative selection of quotes from people's responses, to give a flavour of what Mercurial's users have to say. We have tried to avoid selecting only "positive" or "negative" quotes, instead trying to provide an informative view of responses.

If you responded to the user survey, but do not find an identifiable quote of something you said, please understand that we really did read everything you wrote.

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 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 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.

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:

• general
  • If Mercurial development would grind to a halt right now we'd have a fine product still.
• code

  • Better support (or tips & tricks) to deal with issues between file name casing on diverse environments.

  • Metadata in patches (copy, rename, mode change, ...)
  • A command like "git pickaxe".
  • 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.
  • 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.
  • There are more significant bugs than I would like.
  • I *do not* like the fact that not much is said about multi-head repositories, which is hugely useful. Most of the documentation about working practices says that having a repo per branch is the right way to go, but that only makes sense when you don't have a lot of branches. We have a monthly branch cycle, so managing a separate repo per branch is unwieldy.
  • Ability to push a single branch, not whole tree.
  • An extension to help manage command="" restrictions in ~/.ssh/authorized_keys with hg-ssh.
  • A way to validate (and replace) users when committing at master. It makes no sense for our project to have a commit from somebody that doesn't have access to master server.
  • Streamed I/O.
• usability
  • 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.
  • Some progress indication during a clone would be nice.
  • Conversion of CVS (and maybe SVN?) repositories should be easier.
  • 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.
  • I always get annoyed by the fact I cannot just copy/pase a path name from a "hg status" to a "hg diff".
  • Most people around here like CVS's "recursive from here down" behavior better than "repository wide by default" behavior of hg.
  • Much improved, not similar sounding, verbs (undo/revert/remove/backout etc.).
  • Remove unbundle (use pull instead).
  • There needs to be a simple way for a user to enable such a hook which was pre-defined by the maintainer on the server.
  • I have had ongoing issues with upstream merges. With files I haven't modified, I'm often forced to manually merge them, or am prompted about deleting them because they were removed upstream. It's possible that there is some issue from old hg versions that has affected our repository, but repeated attempts to get help haven't resulted in much. This has been an issue since Xen switched to hg and continues today.
• docs
  • Workflow docs - merging strategies - use one master branch - use various branches, e.g. main, testing, unstable - micro branches, ...
  • Clear useful comparisons vs. darcs, bzr, subversion, and perforce.
  • Nice if the documentation went into more detail about common tasks.
  • More best practices docs.
• stability, testing
  • Maybe testing should be done with a cold installation from time to time.
  • Needs better regression testing for the Windows version.
  • More tests. I.e., an scm is responsible for my code and I want to have a ridiculous level of confidence that it's not going to screw up or otherwise lose anything.
• process
  • Publish version 1.0!
  • More frequent releases.
  • Annoucements in the style of Junio Hamano's "What's in git.git" would be nice.

What could we do to see wider use of Mercurial?

49 of 63 respondents (77%) answered.

Interesting quotes:

• communication
  • Tell people. I only learned about hg by accident via git (which I was playing with at the time).
  • I think the screencasts that are all the rage (Rails) are good for an intro too.
  • Guerilla advertising! Get articles on IBM developerworks, newsforge etc.
  • Do a benchmark on a large repo and post the numbers on above sites, along with the numbers for other SCMs.
  • There should be more news on the website.
  • Communicate the Mercurial development status more clearly: what's planned soon, who's working on what etc.
  • A "weekly report" on some blog or on the wiki with the most important checkins and discussions on the ML.
  • If you are new and you go to the website you think there is almost no change in this project.
  • Advertise more on the kernel mailing list.
  • Knowing there is someone to help you on IRC is great.
  • It would be good to post some articles/reviews to lwn.net, kerneltrap.org, osnews.com and so on.
• getting started
  • Explain how it compares to others. Especially bzr, which seems to be very close.
  • Help with getting started for cvs users (their biggest peeve is that hg clone takes longer than cvs co).
• process
  • Do regular releases. I see no point in putting a schedule in the Wiki roadmap and then ignoring it. This is lame. Better remove the deadlines from the Wiki and do at least one release a month with the stuff you have at that point, better more often (like git does), and put a release note in the Wiki to document the progress.
  • Release version 1.0!
  • Following the advertised way to submit bugs and patches and seeing them ignored is a bit frustrating (speaking from someone else's experience).
  • Continue to make hg better/simpler/easier and rely on the resulting positive word of mouth.
• other ideas
  • Evangelize major open source projects one by one (e.g. Python, Trac).
  • Look to make the Trac integration "supported" by default.

  • Another idea would be to approach the various project hosting websites (Sourceforge, Berlios, Savannah, ...) to offer hg trees. For example, I work on GRUB, which is hosted on Savannah and still using CVS...

  • It might be worthwhile to find an important Linux subsystem maintainer who's dissatisfied with git and work with them to make hg fit their needs. People can't *really* be satisfied with git... can they?

Documentation

Do people use the wiki?

55 of 63 respondents (87%) answered.

Do people find the wiki useful?

50 of 63 respondents (79%) answered.

Interesting quotes:

• The wiki often doesn't distinguish between features in various releases, and instead documents the top-of-tree.
• When it was unavailable for a few days I really missed it, and it made me realise that I'd like the ability to have a local copy of some of the user documentation.
• I generally only find it useful for looking up information I already know is there.
• I have found that less than tech-savvy users, especially in France, are not used to use wikis so it should not be the only point to get docs.
• I find it sad that one has to create an account in order to contribute to it. I will not create an account.
• Too little information, and needs more 'tips and tricks'.

• I would prefer something in a PostScript / PDF format which can be printed out if it is large, such that it can be read, while working on something else.

Do people find Mercurial's built-in help useful?

49 of 63 respondents (77%) answered.

Interesting quotes:

• There are no man pages for extensions.
• It can tell you what commands are there, but not really what they do.

• I like it so much that we copied it in Xen

• It's not useful for figuring out what Mercurial's view of the world is with respect to changesets and file revlogs.
• I'd like a more multiple level approach like p4.

What are people's favourite pieces of user documentation?

41 of 63 respondents (65%) answered.

Other mentions:

• http://www.macromates.com/

• The TeXBook. It explains *everything*, but in layers so that you can understand to whatever level you need.

• http://www.xulplanet.com/ for learning xul

• The original Unix documentation (man pages and papers) from back in the old pre-linux days: brilliant
• git docs (man pages, howtos and internals description)

Interesting quotes:

• selenic.com seems slow, making the wiki a little annoying to work with.
• A profound documentation wiki (like ubuntu-fr.org for example...).
• I think the screencasts that are all the rage (Rails) are good for an intro.
• If I have to resort to the documentation, it's already not my favourite.
• In general I prefer documentation that is split into two parts: task-based, plus a reference manual
• For the rest, I prefer a really clean, understandable command set based on an easily comprehensible "model" (that is described by diagrams and good examples of usage).

Getting help

Have users tried to get help from other people?

50 of 63 respondents (79%) answered.

Interesting quotes:

• Vincent Danjean, the maintainer for the Debian package, is very quick to respond and immensely useful. He is what I wish every Debian developer is.

Have people been successful in getting help from others?

25 of 63 respondents (39%) answered.

Interesting quotes:

• The irc channel is great, seems that there are knowledgeable people always there. Some of the issues I've had had no easy solution, and they have talked me through on many of them.
• Mercurial mailing list is always very good.
• People were kind, but I didn't had any positive return to the features requested there.
• People on irc and the mailing list are super helpful.
• The Mercurial community is more polite and helpful than most.

Have people used the bug database?

52 of 63 respondents (82%) answered.

Interesting quotes:

• Searching for "bugs" on the mercurial shows up nothing.

Do people find the bug database useful?

12 of 63 respondents (19%) answered.

Interesting quotes:

• I've had my doubts about its effectiveness... seems that there hasn't been a big push to clean out a lot of the bugs living there.
• The answers were not good.
• It's not so great for finding a bug.
• It's a bloody pain to use.

Do people subscribe to the mailing list?

54 of 63 respondents (85%) answered.

Interesting quotes:

• I like the atmosphere and community there. It's obviously a very good example of how a free software project can really mature and develop.
• The mailing list was more helpful before the bug tracker has been installed. Now most emails are patches or notification emails from the BTS. My impression is that the discussions were livelier before the advent of the BTS.
• I'd prefer that the bug reports were not sent to the main list.

Do subscribers find the mailing list useful?

36 of 63 respondents (57%) answered.

Interesting quotes:

• I do not like the patchbombs very much but recently they do not appear as often.
• I find it a bit too development centric. Might be a good idea to have a list more users oriented too.
• I have the feeling that recently there have been fewer discussions about design and things.
• I do wonder how useful the mailinglist is to users instead of developers.
• Most of the traffic is only of use to developers, not users.

Open forum

Interesting quotes:

• I want to thank you, Matt and all the people working on mercurial for such a great piece of software. You've really done a great job, hope it only gets better.
• I like Mercurial's development model, and I aspire how versed the core developers are. Matt is a very good leader, I like almost all of the decisions he makes.
• I know it would be useful for me to go on about things that could be improved in Hg, but I would rather take a moment to thank the developers that have invested their time in making this tool possible.
• "Screw those BitK**per dickheads." Threatening to sue paying customers? Not!
• I think that when used with a GUI or integrated in other software it could benefit a lot to less-techie people.
• It's unfortunate that both Mercurial and bzr are active projects... they seem so conceptually similar. They should really be sharing the same user and developer base.
• Hg seem to be growing in complexity at the same rate it's growing in capability. Could you eliminate 25% of hg commands and retain the same functionality?
• I am concerned by the smaller community and slower evolution of Mercurial, compared to git.
• My hardware is ancient (TP 600X, c. 2000, but 576MB RAM). All the same, mercurial feels a bit sluggish when dealing with a kernel tree.
• What about roadmap? It seems mercurial is not on track very much.... OTOH it works well enough for my use. But version 1.0 would be a good push to get more users.
• It might be nice to have a better picture of what authentication scenarios people have for using Mercurial remotely.

---

CategoryHistorical