Differences between revisions 9 and 10
Revision 9 as of 2006-04-27 07:10:14
Size: 9584
Comment:
Revision 10 as of 2006-04-27 07:13:58
Size: 9609
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:

[[TableOfContents()]]

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.

20

usa

8

france

5

uk

4

germany

2

canada, brazil, austria, australia

1

united arab emirates, switzerland, sweden, spain, russia, netherlands, mexico, japan, israel, czech republic, croatia, belgium

Getting started

How people found out about Mercurial

56 of 63 respondents (88%) answered.

18

read discussions on the Linux kernel mailing list

8

started using Mercurial because the Xen project uses it

8

discovered Mercurial during research via the net (typically Google)

5

found out via friends, coworkers, or collaborators

4

read articles or blog postings that mentioned Mercurial

3

saw Mercurial mentioned on the git mailing list

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.

50

very easy

4

moderately easy

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.

18

wiki pages, including tutorial

5

command help

2

README file

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.

43

work (paid) projects

50

unpaid, open source, and personal projects

Interesting quotes:

How do people obtain Mercurial?

56 of 63 respondents (88%) answered.

27

pull main

27

prebuilt binaries

24

source tarball

8

pull crew

Interesting quotes:

  • Distributions' packages lag too far behind.

What systems do people use?

56 of 63 respondents (88%) answered.

28

i386 (cpu)

16

debian

14

linux (distro unspecified)

14

mac os x

13

windows

11

x86_64 (cpu)

9

fedora

9

ubuntu

7

freebsd

5

powerpc (cpu)

5

solaris

4

sparc (cpu), rhel, gentoo

3

suse

2

netbsd, centos

1

red hat 7, mips (cpu), mandriva, irix, dragonfly bsd

How many people do users collaborate with?

48 of 63 respondents (76%) answered.

12

solo projects only

17

3-8 people

11

1-2

6

9-16

2

17+

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

4

0-1mb

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

How many projects do people use Mercurial with?

52 of 63 respondents (82%) answered.

23

3-8 projects

16

1-2

12

9+

Which extensions do people use?

47 of 63 respondents (74%) answered.

21

none

14

hgk

12

mq

8

patchbomb

3

hbisect

3

gpg

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.

20

8 out of 10

18

7

16

9

1

6

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?

21

cvs

14

svn

10

git

9

arch

6

monotone

5

darcs

4

perforce

3

bzr

2

teamware

2

tla

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

UserSurvey (last edited 2010-10-21 23:30:00 by mpm)