
The State of Version Control: an Infographic - gecko
http://www.fogcreek.com/blog/post/The-State-of-Version-Control.aspx
======
bradleyland
"We asked subscribers to our developer newsletter (788 respondents) and
professional developers via StackOverflow (169 respondents)."

With all due respect to the FogCreek team, I'm not sure these numbers could be
considered a representation of the development community in general. FogCreek
makes Kiln, which according to Joel's (FogCreek CEO) blog is "a web-based
version control and code review system based on Mercurial and tightly
integrated with FogBugz." I know Joel's writing has broad appeal (I know I'm a
fan), but it would stand to reason that there would be a disproportionately
high number of Hg users in these results, would it not?

~~~
tghw
We compared the numbers we got from our newsletter survey and those we got
from Stack Overflow and they were actually much closer than even we expected.
Mercurial gets a slight bump in our newsletter responses, but SVN still
dominates across the board.

~~~
xbryanx
And if you look at questions on Stack Overflow you've got: 532 tagged [Git]
119 tagged [Mercurial] Just to give you a (unscientific) sense of the bias in
the Stack Overflow community.

~~~
sgift
I think this metric is not really useful: Maybe git is just harder to use (no
git/mercurial please, just my first thought on the usage of question tags as a
- unscientific - metric).

~~~
jrockway
By similar logic, PHP is harder to use than C.

~~~
jedbrown
It's not?

------
brown9-2
_And, you'll be increasingly coming across Mercurial, since it's been adopted
by Mozilla four years ago, by Google in 2009, and is preferred by Windows,
Python, and Django developers. (89% of our respondents have heard of GitHub
and 62% of its Mercurial sibling BitBucket.)_

"Adopted by Google" here seems a bit disingenuous; they offer Mercurial as an
option for developers that want to host their OSS projects with Google, it
isn't as if Google's in-house source control has moved to Mercurial.

~~~
reedlaw
What do they use in-house?

~~~
technomancy
The Android team uses git.

~~~
js2
As does Chromium OS, meanwhile Chromium uses subversion.

------
pclark
Out of 1000 respondents:

> 70% of programmers today are Windows based, 16% use Ubuntu/CentOS or other
> Linux, and 14% use Mac OS

Is this a skewed survey towards Microsoft orientated people, or is this the
normal for the developer industry? (hard to say when you are in a bubble/niche
of web startups)

~~~
gecko
This is _probably_ skewed. We did our best to make sure we were getting a wide
swath of respondents by also running the survey on StackOverflow, but even
there, our choice of which tags to advertise the survey with probably biased
the results. I'd take the OS distribution not as an indication of who in
general developers for which OS, but rather just as information on which
percentage of respondents were on which OS. I.e., it tells you about the
survey, not about developers in general.

~~~
streeter
I'm not as convinced this is terribly skewed away from the normal. Outside the
Bay Area, the large organizations that hire thousands of programmers primarily
use Windows for development. For example, go to any Defense Contractor
(Lockheed, Northrop, etc) in the country and sample the computers they use for
dev work. Each developer probably has a Windows box they do everything on.
There might be some Linux boxes mixed in, but those will probably be headless.
Or the developer runs Linux in a VM on top of Windows.

While in the Bay Area, we might think these are skewed because everywhere we
go we see Mac laptops, in reality, the employees at big corporations are going
to outnumber us.

~~~
zwieback
I can confirm this (working at mega-corp) and can also add that a lot of
specialized and embedded tools are primarily hosted on Windows. Even high-end
CAD and modelling tools are primarily on Windows where I've worked.

~~~
andrewem
High-end CAD tools _used to_ be run almost entirely on Unix systems (Solaris,
SGI, HP/UX, etc.). Back in the 1990s Windows systems couldn't handle these
tools the way Unix workstations could, but once that changed there was no
reason to spend far more money on a workstation. Perhaps if Linux had become
popular a few years sooner the transition in high-end CAD would've been from
proprietary Unix to Linux. See for instance
<http://www.ptc.com/partners/hardware/current/support.htm> where support for
various *nix are being phased out by Parametric Technology, Linux included.

~~~
zwieback
Yeah, I remember those days well, we had Unix boxes for CAD and 386s with Win3
for office work side-by-side. I think you're right - the transition to Linux
would have been an obvious choice if the timing had been better.

------
arn
Does anyone else find it surprising that SlashDot is the highest ranked
favorite tech website amongst respondents?

~~~
petercooper
Given that 70% of the respondents are also using Windows, no. But it's a
_good_ thing, really. They're weeks behind with the latest news and decades
behind with their operating systems.. we can't fail! :-)

~~~
fabjan
Reddit is more Windows centric than Slashdot.

------
prosa
Did anyone else notice the that the chart, "Do People Love or Hate their
Version Control System?" was _horribly_ misleading? CVS gets 3.5 hearts, and
SVN gets nearly 4. Meanwhile, _far_ below on the page: "Only 11% of Subversion
users said that they loved using it; the number was zero for CVS and VSS."

~~~
mnutt
The hearts chart also bothered me in that the lines were _diagonal_ making it
difficult to compare at a glance.

------
snowwindwaves
They state in the last paragraph that Ubuntu+CentOS+Other Linux OS market
share in the survey was 16% which puts it ahead of OSX but they chose to
separate Other Linux out in the chart so visually it doesn't seem as
significant.

Maybe I'm used to always reading Linux market share at 1% so I want to see
that big circle even if it is from a non-representational group.

------
MatthewPhillips
Personally I use github for projects I want to link to on my resume and
bitbucket for websites and stuff I don't want to share with the world (yet).
Maybe it's because I'm a novice user who only does the basic commands, but I
see no real difference between git and mercurial.

I use TFS in my professional job and am pretty surprised that so many people
like it. Everyone I work with either hates it or lives with it. Doing stuff
like moving changes from one branch to another is unreasonably hard.

~~~
billybob
Scott Chacon (author of Pro Git, Git evangelist for Github) has said in his
Changelog interview that Git and Mercurial are in fact extremely similar. He
wrote some kind of tool for letting the two work together, so he had to learn
the internals of both to do so. His take was, use either one. Just make sure
you use distributed version control.

------
jcromartie
The infographic makes it look like half of VSS users love it. But later on,
the article states that _zero_ VSS users said they loved it.

~~~
gecko
For each VCS, you had to pick between love, like, meh, bleh, and ptooey (I
don't remember the exact word options). The infographic attempts to just merge
those into degree-of-like, which I believe was done by assigning weights to
passion and then averaging.

~~~
ohashi
I think you missed the point. The graphic doesn't effectively communicate the
underlying data. I was also thrown by the graphic and words. 3
hearts/stars/whatever to me means average. Zero people saying they love a
system to me indicates less than average. I don't fault you for trying to
communicate it the way you did, it makes sense from one perspective, but from
a user standpoint it's confusing when combined with the text.

~~~
gecko
Personally, I agree. I know our graphics designer whipped up one of the actual
bell curve per VCS. Hopefully, we'll post it later.

------
yock
> Only 11% of Subversion users said that they loved using it; the number was
> zero for CVS and VSS. Compare that to the over 40% of Mercurial and Git
> users that love using them!

Is it just me or doesn't this not reconcile with the relevant portion of the
graphic?

~~~
icefox
Same with the "47% of developers use it as their primary version control
system at work" Shouldn't that be more like ~20% given that the two pie charts
for win/mac showed ~40 and ~15?

~~~
yock
That seems to refer to Subversion, which seems to jive with the top bar graph.

------
yannickmahe
A fascinating read.

HgInit.com is the site that got me to Mercurial. I now use it for all my
personnal projects. Unintended side-effect though: pains with working with SVN
at my day job became more obvious.

------
famousactress
I find it a bit surprising (if not hard to believe) that hg is more common
than git in professional use. That said, I don't find it hard to believe that
hg users have more love for their tool than git users.. Before becoming an
avid git user I tried both and found hg's commands much more lucid.

~~~
statictype
Git support on Windows was really poor for some time (I gather it has improved
though), whereas Mercurial pretty much always treated Windows as a first-class
citizen. That may have something to do with it.

On the other hand, I _do_ find it hard to believe that hg users love their
tools more. Generally my impression has been that git attracts a lot of people
who are, shall we say, passionate about their particular version control
system.

~~~
famousactress
Ahh.. The windows bit makes perfect sense. I wasn't aware (not a Windows
user). Excellent point about git's community also. As obtuse as the commands
can be ( _Really? git push :branch_name DELETES a remote branch?_ ), I still
love it. Also, the relatively high number of people who claim to love cvs in
the survey suggests the bar for satisfaction might not be very high here :|

------
jsdalton
The article mentions Kiln (<http://www.fogcreek.com/kiln/>) as a code review
tool. What other code review/collaboration tools are people using with Git
and/or Mercurial?

~~~
markstahler
Reviewboard <http://www.reviewboard.org/>

------
zdw
I wonder how much further along git would be on Windows if it had run better
on that platform historically, and had a better GUI.

The Mac numbers don't surprise me at all, as the large influx of unix people
to the platform are more used to using CLI tools.

(yes, I'm saying that on the whole, Mac users are less afraid of the CLI than
Windows users. Shocker!)

~~~
cincinnatus
Yes, GIT is way more hassle than it should be. I hate that it depends on
cygwin and msysgit is a great start but still a little alien feeling.

I disagree with the blanket statement about Mac users. Developers using Mac
are _not_ Mac users by a long shot. For most of us I know it is a case of the
Mac being a better *nix dev box than the alternatives.

~~~
maw
I agree that many developers on Macs aren't traditional Mac users, but
disagree that OSX is a better Unix. I'd say it's an ok-to-good Unix, but one
where sound, copy and paste, and wireless networking all work--and that it's
these that compensate for other shortcomings as compared to Linux or FreeBSD.

------
igneous4
Bazaar is conspicuously missing. My guess is that "other" is mostly Bazaar.

Aside: would've been neat to see a "version control by OS" pie chart for
GNU/Linux.

~~~
alkaramba
We got exactly four responses for Bazaar and one for Fossil out of nearly a
thousand. They are just tiny in comparison to the rest.

~~~
riffraff
given that 'others' does not seem to be 0.5% of the chart: what else is in
there?

~~~
stonemetal
clear case, and source gear are the only two I can think of that might make
the list.

------
paulgb
Not to nitpick, but the "Most Used Operating System Professionally" portion
misrepresents the data. The area should be proportional to the values, not the
radius. Notice that the Windows XP circle is over 4X as big as the Mac OS one,
even though it's only twice the value.

~~~
tghw
Are you sure those aren't spheres? 'Cause if they were, then it should really
be volume, not area.

------
haberman
I'm becoming less enamored with git over time. I've used it for years (by
choice, and I'm a GitHub user), but have never been a power user.

I'm annoyed at how the very most basic workflows in Git seem awkward, like I'm
working against the tool instead of with it. The simplest example is: I have a
hacked-up tree, but I know changes have been made upstream, and I want to pull
those changes:

$ git pull Updating 73f91c3..0ee9fa8 error: Entry 'README' not uptodate.
Cannot merge.

It's complaining because I've modified README locally, which was also modified
remotely. Every other reasonable version control system I've ever used will
happily merge the upstream changes with my not-yet-committed local changes.
But Git refuses. This is annoying.

What I have to do now is commit my hacked-up, non-compiling, possibly-swear-
word-containing in-progress changes. I really dislike this. To me, "commit"
means "take a finished bit of work and add it to the global history." I
_really_ dislike having to commit something that is extremely unfinished just
because I wanted to integrate some upstream changes.

So what I usually do in this situation is "git stash", "git pull", "git stash
apply." This works ok for the "pull" case. But what if I have multiple sets of
locally-hacked-up changes? Like suppose I was working on one change when I
realized that there's something else I should really fix first. "git stash"
quickly becomes limiting, since you can't name the individual changes, so you
get this list of changes that you don't know what they are or what
branch/commit they were based on. In other VCS's like Perforce, you can have
multiple sets of independent changes in your working tree. Not possible with
Git AFAIK.

Anyway, I'll probably keep using Git, but I'm not as enamored with it as I
once was. I used to figure this was all just porcelain issues that would be
refined over time, but it doesn't seem to be getting any better.

~~~
js2
_It's complaining because I've modified README locally, which was also
modified remotely. Every other reasonable version control system I've ever
used will happily merge the upstream changes with my not-yet-committed local
changes. But Git refuses. This is annoying._

Commit-before-merge is not a limitation, it is a feature of DVCS's. Merge-
before-commit is broken by design, as you are modifying your unsaved work, and
there is no way to get back to your pre-merge state (say you decide the merge
conflicts are too much to deal with at the moment).

So you are correct, git will not let you merge if youmhave uncomitted work
that would be affected by the merge, but it's really just trying to keep you
from losing work, not trying to annoy you.

That said, this is one of the use cases for 'git stash' which will set aside
your uncommitted work. You can then do the 'git pull' and then unstash (stash
pop) your work. The advantage of this is that you can always undo the merge if
you decide it's not what you wanted afterall. With merge-before-commit, you'd
have no such option unless you manually set aside your work.

 _But what if I have multiple sets of locally-hacked-up changes? Like suppose
I was working on one change when I realized that there's something else I
should really fix first. "git stash" quickly becomes limiting, since you can't
name the individual changes, so you get this list of changes that you don't
know what they are or what branch/commit they were based on. In other VCS's
like Perforce, you can have multiple sets of independent changes in your
working tree. Not possible with Git AFAIK._

This is what branches are for. Do not be afraid to commit work in progress...
you can always polish up that work before you share those changes. For
example:

    
    
      git checkout -b feature origin/master
      edit, ut oh, interuption,
      git commit -a -m WIP
      git checkout -b bugfix-1234 origin/master
      fix bug, git commit -m "fixed bug"
      git push origin HEAD:master
      git checkout feature
      git reset HEAD^ # removes the WIP commit, but leaves its changes in your working copy.
    

I hope that gives you a better idea of how you can use branches. You might
also want to spend some time reading up on rebase -i. Basically, start
thinking of your localc branches as independent patch queues that you can
freely edit, reorder, etc until they are ready to be shared. At which point
you can push them out to the world.

HTH.

~~~
brodie
FWIW, Mercurial allows you to do merges against the working copy -- you just
run hg update.

~~~
js2
It does not let you merge if you have uncommitted work, just like git:

    
    
      $ hg pull
      pulling from ...
      requesting all changes
      adding changesets
      adding manifests
      adding file changes
      added 1 changesets with 1 changes to 1 files
      (run 'hg update' to get a working copy)
      $ hg update
      abort: crosses branches (use 'hg merge' to merge or use  'hg update -C' to discard changes)
      $ hg merge
      abort: outstanding uncommitted changes (use 'hg status' to list changes)

~~~
brodie
Sorry, you're right that it does refuse to merge with the working copy if the
changeset you're updating to is not a direct descendent of the changeset
you're currently at (this is what the error about "crosses branches" refers
to).

However, if it is a direct descendent, it will try to merge for you:

    
    
      $ echo b >> a
      $ hg status
      M a
      $ hg pull ../a
      pulling from ../a
      searching for changes
      adding changesets
      adding manifests
      adding file changes
      added 1 changesets with 1 changes to 1 files
      (run 'hg update' to get a working copy)
      $ hg update
      merging a
      warning: conflicts during merge.
      merging a failed!
      0 files updated, 0 files merged, 0 files removed, 1 files unresolved
      use 'hg resolve' to retry unresolved file merges
      $ hg resolve -l
      U a
    

In this example, the upstream repository made a change to "a" that conflicts
with my local, uncommitted change to the same file. It uses its normal merge
machinery to try to resolve the conflict.

As far as I know, Git doesn't allow merges in this situation.

~~~
js2
Oh, that's evil, you don't even need to --force it? :-)

So there's no way to back out of that right? i.e., get back "a's" state before
you ran update?

(Ah, I see from update's help that you have to use --check to prevent it from
touching uncommitted files.)

Hmm.

------
asnyder
No Darcs? Personally I prefer darcs over other distributed version control
systems, unfortunately their tooling is somewhat behind and due to the github
craze we're forced to use git on many projects,it's very sad as the ease, the
features, and simplicity of darcs is in my opinion unparalleled by any of the
others listed.

~~~
danssig
I love Darcs conceptually and I used it for a few years but after moving to
Git I have to say I prefer it. Darcs is certainly cleaner than how Git is
actually implemented (scripts and perl everywhere) but Git is nicer to work
with day to day. The reason is that in Darcs to make a branch you have to
basically check out the tree again. In Git I never need more than my repo
directory. All branch checkouts, etc. happen right in that directory. That may
sound like a trivial difference but in practice this can save _hours_ a week
for the way I work. Git can do most of the cherry picking, etc. that Darcs can
do.

I do miss the ability to check in changes that I only ever want to have local
though. I haven't found a satisfactory way to do that in Git yet.

~~~
aaronkaplan
I agree about the convenience of having multiple branches in a single repo, as
opposed to the darcs way which is one working directory per branch. For one
thing, I never found a convenient way to switch between branches in an IDE
when using darcs. For another, having a separate working copy for each branch
consumes disk space unnecessarily. (Hopefully with the popularity of SSDs
these days, people are less likely to reflexively respond "disk is cheap," but
just in case: with git, all branches of my current project fit on my USB
stick; with darcs, they wouldn't. It also makes a big difference for copying
times.) darcs repos can be deduplicated using hard links, but that only
affects the patch history--the working copy is still duplicated.

[edit: removed question that was answered by sibling post]

------
danssig
Good to see that modern revision control systems are starting to gain on SVN.

EDIT: Removed incorrect statement about 63% stat.

~~~
carson
That is 63% that don't do code reviews. I think it is put together oddly
because I thought that as well at first but later in the description they talk
about code reviews.

------
kenjackson
_CVCSes work OK. But they all miss a critical piece. They aren't nearly as
good at doing one of the main things that a version control system can let you
do: branching and experimenting with your code_

I hear this complaint a lot, but I do this all the time with SVN. Just have a
directory (tempbranches) where you create your branches. It's probably
something I do once a week (and not because I feel limited to only doing it
once per week, but most of my work occurs in my local branch -- and I branch
that one only when I want to do something that is more experimental, but will
take a few days). I'll grant that its not as clean as a DVCS for this, but it
works just as easily. The big difference is that we now have centralized
accounting of this action, rather than it being distributed.

~~~
famousactress
_but it works just as easily_

Um, are you sure? I find branching and merging in git (after three months
using it) much, much, much easier than I did in SVN (after 7 years of using
it).

~~~
kenjackson
Can you expand. Because I've probably done a few hundred SVN branches. And
probably 100 Git branches. The big advantage I had with Git was that since it
is decentralized, you don't have branches on the server (so no need to have a
tempbranch target on the server). But that doesn't seem like a huge deal to
me.

The actual activity of branching and merging seem equally easy to me.

~~~
danvet
With just 100 hundred git branches, I think you're not really using git often
and/or to its potential. On a busy coding day, I easily create a few branches.
If you also count temporary branches on non-development testing machines (I do
driver development on Linux for fun) that can easily reach a dozen.

Now what for? I create branches to test merges with other developers code,
branches before refactoring my in-progress stuff (so I can go back and pick up
the original branch with all its history in case it was a dead-end). I do new
branches for simple fixes, tracking down bugs (versioning all test-patches so
you can check the next day/week what theories you've already tested is
sometimes extremely useful). Sometimes I just do a new branch to get the feel
of starting with a clean slate.

Once a month or so a look at all the branches lying around and delete those no
longer useful.

All this is only possible because git branching is _cheap_. Orders of
magnitudes cheaper than on any central rcs. And the best part is that git
never ever loses anything. git reflog shows you _all_ the states you've gone
through to the current one. So all these branches are actually valuable.

------
mberning
I don't understand our obsession with version control systems. I still find
that SVN meets my needs 95% of the time. I've used git for my projects that
are hosted on heroku, but I've never been so impressed with it that I want to
completely move to git.

~~~
patio11
So I started using git with my latest project, just to get a feel for what all
the Ruby on Rails guys were talking about when they weren't bragging about the
size of their Macbooks. The koolaid is _delicious_. Even in a one-man, one-
repo world, I spend a _lot_ less time fighting my VCS for dominance.

Example from today: I was working on my deploy branch, where I typically only
make to-be-deployed-within-the-hour microchanges. Then I saw another bug, so I
squashed it. Commit. Then I saw another bug. So I squashed it. Commit. Then I
saw a major opportunity for a simplification with a refactoring. Then I
realized the refactoring was under-tested and that failures would be
catastrophic, so I started adding extra tests. Now I'm fifteen commits past
the last deploy, I have code that I'm 85% positive works on my must-not-fail
deploy branch, there is one commit in there which addresses a bug which I want
dead, and it is quitting time.

I have been in this state in SVN before. Recovery is NOT fun.

git branch all-the-work-i-did-today #Creates a new branch whose history looks
exactly like deploy's does.

git reset --hard production_deploy_92 #Moves head of deploy branch to the tag
of the last deploy, essentially forgetting commits afterwards.

git cherry-pick carefully_copy_pasted_hash #Nabs the one bug fix that I really
wanted to deploy today.

Git makes my development and deployment processes better. Transformatively
better, in some cases.

~~~
zwieback
Is this common? Usually we have a hard freeze on a release branch a couple of
weeks before actually releasing it. I'm working on embedded systems so the
test cycles are usually slower due to heavy HW involvement.

~~~
SwellJoe
In web development, outside of large corporations, I'd say that near-realtime
deployment is the norm. Fix the bug, test the bugfix, deploy to servers, all
in the same day. git does work well for this. In Open Source projects, as
well, folks tend to work directly on HEAD and only go back to old
branches/tags for security fixes (if at all). Again, git is tight for this
kind of work; which shouldn't be a surprise since it was built for Linux
kernel development.

Embedded systems have to be damned-near perfect before you ship. Web systems,
not so much.

------
smiler
Biggest statistic is that 60% of people are not using source control
professionally!!

~~~
simonista
I think you misread. It's 63% of people not using _code review_
professionally.

~~~
smiler
Yes sorry, my mistake :|

------
glenjamin
Perhaps it would be a good idea for the readers of HN to try and
collaboratively design a VCS survey, and then distribute it among the general
developer populace (in the hope of gaining a large sample).

A quick google indicates <http://www.surveypirate.com/> as a tool which would
allow large numbers of responses for free, or perhaps google documents.

First step would be some questions though.

EDIT: The OP has been updated to solicit responses from anyone visiting the
page, which is pretty much what I was hoping for with this comment.

------
duvander
For those who want to see what it looked like: <http://yfrog.com/h7kypp>

~~~
las3rjock
Down now for TOS violation, but +1 anyway for the effort. Any chance of
summarizing the infographic textually somewhere?

------
makmanalp
I'd like to see version control usage percent (or types used) divided up
according to type of Operating System used.

------
amitraman1
The learning curve on git is high, but I understand the benefits. We use it at
my current company , but we do make mistakes with it.

Windows + SVN is so easy to use (and so entrenched), I'd recommend to new
developers & students to learn SVN.

~~~
DamagedProperty
Can you explain why the learning curve on git is high? I have been using it
for a couple of months after SVN completely dorked my project. I have not
found git hard to use. What aspect of git is hard to learn?

~~~
kgo
I like git just fine, but it does have over 100 subcommands, way more than any
other source control system. If you're using it on a solo project, you're
probably using 4-5. Don't worry, some day you'll get the dreaded 'octopus
merge' error or some other non-intuitive message.

~~~
DamagedProperty
One thing git has done for me is think a bit about how I work and organize my
code. I love the fact that I can work on a bunch of stuff then spend time
organizing which parts are going to go into what commits. With me being the
only one working on it does make it easier. I am proposing we use git at work
so I would be interested in creating these 'octopus merge' situations.

------
frobozz
I'm surprised at how loved perforce is. Whenever I have to do anything on a
perforce repository I think, "Oh no, not this again!"

~~~
blasdel
Sounds like you've never had to do anything with ClearCase, VSS, TFS, or any
of those other abortions.

Perforce may be a VCS for managers by managers, but at least it's a
technically competent implementation of a bad idea.

~~~
frobozz
No, I've suffered VSS, but that is quite rightly positioned at the bottom of
the love/hate scale (IIRC. They've taken the image down).

Perforce had just under 4 hearts out of 5, with Mercurial and Git being just
over 4 out of 5.

------
zinssmeister
for <http://www.virtualrockstars.com> I am using SVN, simply because that's
what I used before and I didn't know of Git being so awesome at the time. But
I must say SVN is still pretty good... I agree that you can't love it compared
to Git but its pretty pretty good.

