Farewell to SVN, Git Becomes "Unique": GitHub Announces the Elimination of Subversion Support 13 Years Later

Compilation | Nuclear Cola, Tina
Do you still remember SVN under Git's absolute rule?
Next January, GitHub will remove Subversion support from GitHub. com, and GitHub Enterprise Server will also follow this action in the near future.
GitHub is the world's largest Subversion host, but now due to the evolution of maintenance costs and version control, GitHub is phasing out this service.
1GitHub bid farewell to Subversion
GitHub introduced Subversion support in 2010, when the layout of version control software was very different from today. Most people used the centralized version control system Subversion, which had a decade of development history, and Git was a new thing. At that time, no one had anticipated that distributed version control would eventually take over centralized version control, let alone that Git would become mainstream in a decade.
Now, thirteen years have passed, and up to 94% of developers are using Git, while Subversion is much rarer than before. Moreover, according to GitHub, only 5000 repositories receive SVN requests per month, of which only 0.02% are sent through Subversion endpoints.
Scott Chacon, co founder of GitHub, tweeted, "Thirteen years ago on April Fool's Day, GitHub released the best April Fool's Day post ever: SVN is fully available on GitHub. Although it has a long history, now it is finally coming to an end
Some netizens expressed surprise at this: "GitHub still supports SVN to this day?" Providing SVN on Git backend is not a common method. For example, GitHub's old rival, GitLab, only supports hosted services such as AWS CodeCommit and Cloud Source Repositories from Git and the largest cloud provider, while Azure Repos has never had a Subversion interface.
GitHub's discontinuation of Subversion support has also sounded an alarm for other companies. Joost de Valk, strategic leader of Newfold Digital WP, commented, "GitHub is phasing out Subversion support. Perhaps it's time for WordPress to stop using Subversion
Why has Git become the only player in the version control market?
According to the 2022 Stack Overflow developer survey report, Git accounts for approximately 94% of the current version control software market share, followed by SVN (Apache Subversion) and Mercurial.
There was a time when SVN and Mercurial performed outstandingly, and I believe many people with over ten years of development experience would remember them. But now, it's clear that Git has become an absolute winner. Now, let's recall the evolution history of version control together.
Apache Subversion
Subversion (SVN) is an open source version control system that maintains source code through a central server; Any user who intends to change the code can access these files through the client. Compared to the distributed model used by Git, the client server model of SVN appears more old-fashioned, with changes being stored locally and distributed to the central history record (and other branches) when pushed to the upstream code repository. In fact, SVN is indeed based on previous version control, initially aiming to become a highly compatible successor solution to CVS (Concurrent Version System). Some friends may not be familiar with CVS, which was originally released in 1982 as a front-end and extension of version control system (RCS).
The previous generation version control solution mainly focused on software construction methods from 10 to 15 years ago. At that time, the software would be built into a centralized code repository, and all the added functions would be merged into a single backbone. Branches themselves are rare, and even if there are, they will eventually be absorbed into the trunk. Various important files, especially those large binary files, can be "locked" to prevent other developers from making changes while we are working on them. In addition, files, branches, labels, and everything else exist in the form of a directory. This model is very suitable for centralized development teams, and the final result is a specific version that can be distributed through CDs or download links.
SVN is a free open source version of this model. As a typical representative of paid client server version control systems, Perforce has certain appeal in large enterprises (especially Google); But for users who don't plan to spend extra money on it, SVN is a good choice. Many small companies (including ourselves) initially used centralized version control to manage code, which has even become a habit and preference of many development teams.
But over the past decade, there have been disruptive changes in the way engineering organizations operate. No longer working on a single code repository by the central development team; We are now facing multiple independent teams, each responsible for one or more services. SVonC is a version control expert who has helped many companies get rid of SVN. He believes that SVN is a solution designed specifically for "less agile working methods". This has hindered management, code repository creation/registration, and regular development workflows. Correspondingly, distributed models are more agile in these areas. I believe that the recent growing trend of remote work will further impact these closed environment systems
Another reason why SVN is becoming increasingly unpopular is that Git has proven himself to be better and stronger through facts. Senior software engineer Quentin Headen used SVN when he first started working. In my opinion, SVN has two fatal drawbacks. Firstly, it adopts a centralized design, which means that the SVN server must be running to receive changes submitted by developers. Once the internet fails, the trouble becomes greater. Secondly, branches are a burden. Once a branch is created, it cannot be deleted (if I remember correctly) 。 Although there is a command that can delete a branch, it will still be retained in the history record. Git branches are easier to use and can be directly deleted when necessary
It is obvious that with the birth of the new generation version control system, SVN has lost its advantageous position. And it should be noted that Git was not the only one who impacted SVN at that time.
Mercurial
That's right, Git is not the only member of the distributed version control family. Nercurial and Git also made their debut in 2005, achieving a status in the martial arts world that is also within the realm of Bozhong. But in the end, the world belongs to Git, which I believe everyone has already seen.
At the beginning, Mercurial seemed to take better care of developers who had used early version control systems. VonC pointed out, "This is somewhat similar to the battle between VHS and Betamax (two tape formats)
The core developers of Mercurial, Rapha ë l Gom è s and Pierre Yves David, mentioned that to this day, many large enterprises are still using Mercurial in some form, including Mozilla, Facebook (which may have been transferred to Mercurial's Rust ported version, named Eden), Google (which retains some Mercurial functionality in its Piper custom version control scheme), Nokia, and Jane Street.
Today, Mercurial's core advantage is its ability to scale on extremely large projects (handling millions of submissions and millions of files). Over the years, numerous companies have contributed to performance improvements and specialized features, making Mercurial a viable choice for managing extremely large monorepos
Ry4an Brasse from Google explains why Mercurial still has vitality: Git has been tightly integrated with file systems. Even GitHub treats code repositories as files on disk for access. However, the concurrency requirements of a large number of users executing submissions for a single code repository will definitely exceed the file system's access capacity limit. Google and Facebook have shown that Mercurial can adapt to such data storage needs, but Git cannot. However, with recent releases such as Git v2.38 and Scalar, this The advantage may gradually weaken
But Mercurial has another skill in attracting customers with a large amount of Monorpos - portability and scalability. It is written in Python, so it does not need to be compiled into local code. With a Python interpreter, it can become a viable version control option on any operating system. Mercurial also has a powerful extension system. Gom è s and David explained, "The extended system allows users to make adjustments to various aspects of Mercurial, including custom behavior or integration into existing systems, which is very popular in enterprise environments
Nowadays, Mercurial still has many hardcore fans. The project is also quite active, with Gom è s and David still contributing code, managing the release cycle, and holding annual meetings. Although not considered a leading tool in the market, Mercurial firmly holds onto its position.
Why did Git laugh until the end?
Looking at the basic pattern of version control in 2022, it is not difficult to understand why distributed version control has become the preferred solution for software developers. But why is Git's market share so much larger than Mercurial? They were born at a similar time and have similar functional configurations, giving them a sense of both being born in Yu and He Shengliang. The reason given by Brasse is, "For personal projects, I would choose Mercurial. But if I were to start a company, I would use Git to avoid issues such as retraining and difficulty getting new hires started
Mercurial also has its own advantages, and SVN users will feel very familiar with its design and centralized operation. VonC said, "Mercurial is actually faster to get started and feels more familiar to use because it is somewhat similar to Subversion, only using a distributed model." However, this overly faithful approach to old times may not be a good thing, This has also become a reason for opponents to reject Mercurial, because in today's era where decentralized development has become mainstream, there is no need to shell traditional tools outside distributed models
As for why Git won overwhelmingly, it may be simply attributed to its powerful platform and considerable initial user base. Gom è s and David admitted, "The reason why Mercurial lost to Git in the early 2010s was partly due to the rapid development of GitHub at that time, and partly because the Linux community had a natural identity with Git
Although Mercurial initially held a favorable position, this advantage gradually dissipated over time. Brasse believes that "Mercurial's initial positioning was to provide a well-designed and seamless user experience through a built-in web UI. Although GitHub did not provide Git with the same level of web user interface and coherence, the large group of contributors and the charisma of creators ultimately firmly suppressed Mercurial
The corresponding large group of contributors is naturally an avalanche of feature releases; In addition, the focus on user needs undoubtedly enabled Git to successfully gain considerable market share. Nearly 15 years ago, some people once compared Git to the "Hundred Battles of the Dragon" (a special agent film protagonist who is particularly skilled at using small objects around him to achieve unexpected surprises), while Mercurial was more like "007". As long as we are familiar with the command line, Git can help us piece together customized solutions for almost all problems; Mercurial, on the other hand, is relatively more demanding in terms of work and, if appropriate, is faster and more efficient. In the face of the current situation, his latest viewpoint is that "I was initially least satisfied with Git's user interface, but it has gradually made improvements over the years (I am currently using an Emacs based Git front-end with a good experience); while Mercurial's main drawback is its slow execution on large code repositories, and it has not been resolved until now
Like MacGyver in 'Hundred Battles of the Dragon', Git has been improvising and meeting challenges. And like James Bond, the classic male lead of 007, Mercurial also adheres to his own style of action - in some cases it works well, but sometimes it can be quite awkward. Brasse believes that, We can experience the difference between Git and Mercurial in handling new features through an example, which is the 'config' command. Both 'git config' and 'hg config' are commands used to edit user email addresses and other settings. The 'git config' command will automatically modify '~/. getrc' for the user And in most cases, it is correct. The creators of Mercurial firmly reject all submissions that can edit configuration files. On the contrary, 'hg config' only launches a text editor on '~/. hgrc'. This is like mocking us, programmers who are intimidated by text configuration files are like doctors who can faint - they are all unqualified
In summary, although Git seems to have become a niche in the version control market, there are always more ways to solve problems in this world. If you are feeling frustrated with some of the current options, it's worth exploring more. There must be other ways, and there must be other new ideas worth learning.
Reference link:
https://www.i