The number of projects using Git has passed the number of repositories using SVN at Eclipse, making Git the single most popular version control system for Eclipse projects. The transition to Git only started in earnest after this Summer's release of Eclipse Indigo, although Git has been available since just after the Helios release.
Whilst many projects have already made the move over from Subversion and CVS, the vestigal remains of many projects are still in a CVS or Subversion repository. These are likely to be cleaned up after the Indigo SR2, which is due out in February 2012. As the highlight shows, CVS is scheduled to become read-only at the end of 2012, but it's likely by the time Eclipse Juno ships in Summer 2012 there will be no CVS repositories left in use in any case.
What perhaps is more interesting is that the growth in Git projects at Eclipse hasn't come from the replacement of CVS repositories, it's come from the replacement of SVN repositories. As of now, CVS makes up just under 40% of the repositories at Eclipse, and many of those are the historic projects which have always existed at Eclipse, such as the core Platform and IDE components. These are waiting until after the Indigo SR2 release to fully move over to Git. The proportion of SVN repositories is diminishing quickly, with just under 20% of projects now using Subversion. Partly, this is because it is easier to automate the import of a SVN project to Git without needing access to the administrative files behind the covers; but it's also due to the existence of some of the stalwart projects not being able to move for historic reasons from CVS whilst other newer projects are more agile.
Meanwhile, at Apache, there has been a read-only git mirror of projects on the official Apache Subversion repository for a while. However, it took a passionate post Apache considered harmful in response to CouchDB's request to move to git as a the source code master. Some have put that down to the existence of the Apache Subversion project; but in fact, Subversion has historically been the repository of choice at Apache, even before the Subversion project moved there from collabnet.
Update: there has been a proposal to allow incubator projects to use Git at Apache, which is likely to see some initial Git resources being put forward for administration of Git repositories. Over time, if successful, this may lead to more projects moving towards Git in the future.
Google Code relatively recently (in the last six months) allowed projects to choose between Git and Hg as their distributed version control systems (initially it was only Hg that was supported). Since then, the growth of Git repositories has blossomed and a number of Hg repositories have been changed over to Git repositories. A search of git against Google Code returns 5m results, whilst a search of hg returns 16m results. (Google initially added public support for Hg in April 2009; so Hg has been available for 2½ years now, compared with Git's ½ year at Google Code.
Bitbucket, acquired by Atlassian last year, has also offered Git hosting as well as its initial Hg support. Although Bitbucket don't release the number of projects using either version control system, searching for hg site:bitbucket.org gives 16m results and git site:bitbucket.org gives 5m, numbers very similar to the Google Code numbers (although BitBucket has been providing Hg repositories for longer than Google Code has).
Whichever way you look at it, Distributed Version Control Systems are becoming the norm rather than the exception. Developers starting out today are living in the GitHub generation.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
/articles/rapid-startup-of-your-cloud-native-java/en/smallimage/logo-1680293937095.jpg){kind=logo}
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
/presentations/java-compiler-intermediate-representation/en/smallimage/chris_seaton-s-1679038354209.jpg)
/articles/series-apache-kafka-streams/en/smallimage/apache-kafka-article-series-logo-small-1673455781546.jpg){kind=logo}
/presentations/jfr-observability/en/smallimage/Ben Evans-s-1675024642432.jpg)
/articles/secure-kafka-cluster-strimzi/en/smallimage/securing-a-kafka-cluster-in-kubernetes-using-strimzi-small-1671647644310.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/graalvm-java-compilers-openjdk/en/smallimage/small-image-jdk-2023-1671096273181.jpg)
/articles/java-jvm-trends-2022/en/smallimage/InfoQ-Trends-Report-small-1670863712433.jpeg)
/presentations/java-shared-memory-files/en/smallimage/peter-lawrey-s-1669107216422.jpg)
/articles/josh-long-spring-6/en/smallimage/logo-1669141674434.jpg){kind=logo}
/presentations/devops-java-devs/en/smallimage/Ix-chel Ruiz-s-1669107288266.jpg)
/presentations/java-upgrade-path/en/smallimage/Andrzej Grzesik-s-1667476313077.jpg)
/presentations/log4shell-security/en/smallimage/Simon-maple-s-1665986617483.jpg)
/presentations/loom-java-concurrency/en/smallimage/Tomasz Nurkiewicz-s-1665739004716.jpg)
/presentations/jit-aot-tradeoffs/en/smallimage/qcon-plus-s-1665738630666.jpeg)
/articles/shift-left-api-standardization/en/smallimage/GettyImages-1059510610-1664896147152.jpg)
/presentations/empathy-software-development/en/smallimage/qcon-plus-s-1680292453897.jpeg)
/presentations/operationalizing-ai/en/smallimage/qcon-plus-s-1680292123806.jpeg)
/articles/culture-trends-2023/en/smallimage/InfoQ-Trend-Report-logo-1680287660356.jpeg){kind=logo}
Community comments
It's a no-brainer.. once you switch.
by Roopesh Shenoy,
Subversion, Git and between
by Semen Vadishev,
It's a no-brainer.. once you switch.
by Roopesh Shenoy,
Your message is awaiting moderation. Thank you for participating in the discussion.
The only hurdle in adoption is the mindset - I see this as a when rather than an if, that everyone will start using distributed VCS. IMHO, CVS and Subversion need to be kept on life support just long enough to let everyone switch to git/hg smoothly. There is no point in investing more resources in adding more features to them.
Even for those who want to stick with cvs or svn, they already have all the features they need.
It seems like a paradigm shift when people move from centralized vcs to dvcs, and many enterprises will still be slow to move, but once you do, you never ever go back!
Subversion, Git and between
by Semen Vadishev,
Your message is awaiting moderation. Thank you for participating in the discussion.
Subversion as a centralized VCS induces certain rules for development process:
1. There is one single repository, all the work done by contributors is in one single place;
2. Developer must be online in order to commit, there are no offline commits. Thus you have to commit often;
3. The common practice is to give access to certain branches only;
4. "Branch then merge every time" is not that common practice like in DVCS world.
The Subversion project itself is a good example of how these rules play together. Do they play bad? In general, it depends on the particular process and its metrics. Success of Git and Mercurial shows that Open Source world prefers its own rules. Take a look at GitHub — they've broken all the "centralized" rules above and they are successful.
But I believe that it doesn't work for all the cases. Most of developers work on commercial software, or enterprise, if you will. And, I believe, in this area Subversion has a great advantage over Git et. al. — it makes things more manageable. Take a look at the rules once again — they actually help managers do their work.
Sure fans will argue that Git is much more superior feature-wise, etc. And that leads me to the "between" part of my comment:
Our team has developed a tool which makes Subversion and Git work together — subgit.com
It's not that nasty git-svn thing. In general SubGit is a server-side solution which allows you to use any tool — svn or git. So if you create a new revision in Subversion repository SubGit immediately translates it into corresponding Git commit and vice versa. After SubGit installation you stop all the holly wars and use the tool of your choice.
I believe such hybrid approach is extremely flexible and it works pretty wel for both Open Source and commercial development processes.