Conclusions from the Mercurial user survey
This is a condensed set of impressions distilled from the UserSurvey. This page focuses less on what people like about the status quo, and more on things they'd like to see fixed, and how we can do that.
Mercurial's users are generally very happy with it.
- "I consider Mercurial the best version control system on earth."
Keep it simple
People have a few principal reasons for choosing Mercurial over other revision control systems:
- Performance and scalability
- "Speed, speed, speed :)"
- The simplicity and small number of underlying concepts
- "Mercurial's conceptual model is clean and simple enough to carry around in my head."
- Ease of use: a small, but powerful, command set
- "I feel there isn't really any learning curve."
While there's always pressure to add new features to the software, this is in some respects a fool's errand, because new features run directly counter to the conceptual simplicity that people like so much. A few people had acerbic comments on the alleged feature bloat and loss of clarity of git and bzr in particular.
Process issues
There were quite a few complaints about the development process around Mercurial.
- Releases are not frequent enough; they've been occurring roughly once a quarter recently. Since the pace of development is fast, and vendors only ship official releases, users who don't live on the bleeding edge are often three or more months behind the times.
- A specific suggestion was to follow a Gnome-style model and issue releases on a regular cycle, for example once a month.
- The bug database is seen as a dumping ground, rather than something that's actively triaged and worked through. People don't like submitting bugs and then having them languish for months.
- We should do periodic bug triage runs, and focus on reducing the number of open bugs.
Communications
A number of people were not pleased with how Mercurial developers communicate with the user community and the outside world.
- It's hard for busy non-developers to tell what's new in any given release, what features or bugs are being worked on, or what topics are under active discussion.
- Many people would like to see a periodic (weekly?) summary of development, mailing list, and IRC activity.
- The traffic on the mailing list is perceived by many as centred around the development of Mercurial, rather than its use.
- It may be time to split the mailing list into two, one for developers and one for users.
Documentation
People are generally satisfied with Mercurial's documentation on a local level (for example, built-in help), but not so much with the depth of coverage of bigger issues.
- A number of people want a "proper" manual. The Subversion manual is most often cited as the example to emulate.
- Many users would like to see more "best practices" and "tips and tricks" guides.
- The wiki documentation is unclear in terms of what version of Mercurial any given page applies to, and updates are patchy and infrequent.
Code
While people are generally very happy with Mercurial, many would like to see a number of issues with the code addressed.
- Proper support for rename handling during merges is critical, far more important than anything else.
- The ability to commit frequently, then collapse their commits into one before pushing.
- RCS/CVS keyword expansion.
- More focus on fixing existing bugs.
- Eliminate duplicate commands, and disambiguate commands with similar-looking names.