It's important to note that this graph is generated with data collected from people who have the popularity-content Debian package installed [1]. The "vote" metric it provides is probably a more accurate method for comparing which of the packages are in active use (it records accesses of the package's binaries in the last 30 days).
I dunno, git spawned a revolution in how we think of version control (even mercurial came out of the initial discussions of git); that's a pretty big deal.
Care to explain how Linus got it wrong? I've never used Monotone, but searching the web I could't find a single thing in which Monotone was better than Git (although I did find information of the opposite kind).
Monotone got the user experience right. The git interface simply exposes the atomic operations of commit-tree management. Monotone, on the other hand, provides an abstraction on top of that which maps quite well to how people actually use a DCVS. Doing anything more than the standard edit-commit-fetch-merge-push cycle on git is like casting an arcane spell. The equivalent operation on monotone is either a) nothing, because monotone automatically handles that high-level operation for you, or b) intuitively obvious and simple to construct.
More fundamentally, monotone records both manifest and diff history, which from the git point of view is entirely redundant. However it allows monotone to do much more sophisticated merge handling than out-of-the-box git, and better captures the human intent of a changeset. It allows monotone to correctly handle copy operations, for example, which is relevant in the context of history-rewriting operations.
Fair point. How about, git spawned a revolution in how the masses think of version control?
I've never used monotone, but my vague impression is it was indeed influential / ahead of its time, but didn't have enough of a focus on performance to really catch on. But that's totally uniformed speculation on my part :)
(And certainly kernels existed long before Linux... ;)
That is a fair assessment of monotone, both in terms of influence and performance, although recent releases have gotten better now that there are a few select large projects that use it (Pidgin, primarily).
Monotone uses a sqlite relational database for the code repository, with built-in synchronization/replication. It uses a PGP-like PKI and digital signature system for its trust rules (allowing for a trust-less store-and-forward architecture that still none of the other DCVS systems support). It redundantly stores both revision history and content diff views (two equivalent ways of serializing DCVS trees), and automatically keeps the two synchronized. It is extremely smart about merging and branch handling (the monotone-dev list is wonderful place to find analysis of edge-case merge behvior). And it did all of this back in early 2003.
Monotone was ahead of its time. It's only “problem” was that its core developers chose to focus on correctness and user interface over optimization, delaying work on performance and scalability until such work would actually be needed... which was much sooner than they expected. Linux was orders of magnitude larger than anything that had been done with monotone at the time. This may be an urban legend, but I've heard it said that ‘git’, the ‘stupid version control system’ was named such in part because it was a grotesque simplification of monotone's sophisticated framework, which Linus Torvalds did hold in high regard.
Monotone is the Lisp of distributed version control... venerable and unsurpassed by anything that followed, but utterly irrelevant today.
I keep tacking RCS onto the ends of these, too :) It keeps surprising me - Mercurial passed RCS ~ last June, and Bazaar passed it in roughly June of this year. It gets a lot of usage still.
This whole article has been rendered silly based on this observation. Yes git's popularity has increased and passed subversion but it was a long time coming and not an explosion at all.
I'd imagine that many projects moving to Gitorious/GitHub as opposed to, say, SourceForge has a role here. According to Wikipedia GitHub gained 1 million new repositories between July 2010 and April 2011. Sourceforge currently has some 300k projects. Not completely an apples to apples comparison but I'd think it gets the general idea. Technically, Git lends itself to "social coding" much better than SVN IMO.
Also, last time I checked, SourceForge has an application process involved in establishing a repository, while Github is just "register and create as many as you like"
With many interesting open source projects migrating to or being started on GitHub, almost everyone depending on such tools will install Git for client usage.
It doesn't necessarily mean Git is that rapidly surpassing SVN in actual use as repository, that is likely to happen way slower than the growth of the install base.
Every use of git is a repository, it's the nature of the distributed beast. In fact I would argue the opposite, git probably has a few orders of magnitude the number of repositories than svn does; even the servers I use for production deployments have 10s of git repositories on them.
In a few cases; gettext recommends autopoint, which depends on git, so it will be installed automatically if someone installs gettext.
A few packages depend on gettext that I wouldn't have expected, like blender. This might be a mistake, but anyone who installs Blender will also install git, without ever using it.
Another explanation could be that some packages started having Git as a requirement or dependency. I seem to remember there used to be a package related to the KDE desktop that required the SVN client. I'm not saying Git isn't becoming increasingly popular, but strange jumps might be explained by dependencies or renames, too.
I'd like to suggest that git growth, enhanced by the network effect of github, might also be down to the the ease of entry into using version control provided by the excellent freely available documentation and tutorials.
I'm a one man team, by no means a guru but a competent coder, and git was the first version control system where I could make it past the documentation and get to actually using it day to day. I knew I should be using something, git was the something that made learning and implementing it very low cost.
As a ratio, subversion has more people who use it recently than git does. Interesting, you would think that if people were using git, they would be using it much more frequently than subversion (due to local commits).
So someone who frankly hates git and just uses it to clone a repo someone else made with git, while keeping all their own code in other systems, will be measured as 'voting for' git.
Personally, I think both git and hg are broken in different ways, but either still beats svn. Why do git users (as it seems to me) constantly evangelize their product over all others?
I wonder how many people use git primarily for "git clone <github url>" and that's about it?
I have to admit we still use svn at work (although I've started using git at home on personal stuff) but at the moment the most frequent task I use git for is still simply cloning stuff from github.
At work, before we switched to Git, I used the git-svn bridge. It feels kind of hackish, svn-externals don't work and working with remote branches is doable but you have to be careful when merging ... that being said, I did extensive work with local/remote branches with git-svn and I never saw anybody actually branching / merging in SVN.
I would never go back to SVN. And this is not a zealot-thing in which I'm stating an opinion to protect an investment -- Git is so much better that it isn't even funny.
I agree I prefer git (and also agree that 99% of svn usage in our environment doesn't involve any merging), I think it's just that svn is filling our need for a remote backup/storage for the source code so we're sticking with that for now.
That said we are a very small team and all in the same office so it hasn't been an issue.
I suspect we will slowly start moving new projects over to git though.
To this day, I've yet to hear an argument for git's superiority that wasn't predicated on:
- The assumption that hiding your work in a local branch is somehow a general feature instead of being detrimental to communication and optimized for Linux's development model, or
- Based on a 2003-era understanding of SVN and its support for merge tracking, branch switching, etc.
I keep hearing a lot of enthusiasm but not much to back it up. Do you have a different take than the above?
I wonder where TFS would be on this graph. Not that I think it competes well on merit with these others, but it still has some market forces pushing in its favor. It would be interesting to know how it compares.
Assuming tfs is not toyota financing services it appears tfs is microsoft's souce code management system and therefore is most likely not going to show up on debian's popcon.
This is just a guess, but I get the feeling their market share is probably not too large. We use it at my current job, and I actually enjoy using it. The integration build system combined with work item tracking and testing is nice if you have the ability to tailor your companies workflow to the "TFS way" (we are only partially there, still tracking bugs in our legacy intranet site). That said, it truly is a beast to setup/configure/maintain, to the point where I can't imagine any small MS shop bothering (esp. ones w/o a partner license and decent inhouse servers and possibly a build/deployment guy).
My last employer was still on sourcesafe (shudder!) when I left last year, and I'd bet they'll eventually go with something from SourceGear or Seapine before heading down the TFS path.
pretty sure any developer is likely to have several of these installed; I know I've needed to install them to pull stuff from various open source repositories, regardless of the fact I use git for personal projects
Indeed. E.g., I am using git for more projects than I use mercurial. To these projects, however, I just submitted a limited number of change sets. Most heavily I am using mercurial instead, which I also would choose for future projects. Maybe it would more accurate to measure the number of submissions per time interval.
It's important to note that this graph is generated with data collected from people who have the popularity-content Debian package installed [1]. The "vote" metric it provides is probably a more accurate method for comparing which of the packages are in active use (it records accesses of the package's binaries in the last 30 days).
[1]: http://popcon.debian.org/