Size: 9584
Comment:
|
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.
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:
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.
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.