Subversion vs. Git: Choosing the Right Open Source Version Control System
As with everything in the open source world, version control systems (VCSs) come in several flavors. The grandfather of open source VCSs is CVS, a tool that was the de facto standard in the industry for several years until the likes of Subversion came along and made it almost obsolete.
All the VCSs are broadly categorized into two categories:
- Centralized version control systems -- The repository is centrally stored on a server.
- Distributed version control systems -- Every client has the entire repository stored locally.
Choosing the right type of VCS for a project depends on several things, including:
- The types of files you are working with
- The kinds of people who are going to use the VCS
- The operating systems they use
The first choice you need to make, however, is whether to use a centralized system or a distributed system, which depends on your preference and the relevant experience with the VCS. Since Subversion and Git are the most popular in their respective categories, I have chosen to match them against one another in this article. They both have different advantages. To help you choose the right one, I will explain their major differences and then list the advantages and disadvantages of each.
Difference in Subversion and Git Version Control
Subversion currently is the most popular centralized VCS. In 2000, CollabNet, Inc. began seeking developers to build a replacement for CVS that would maintain the CVS fundamentals but fix its most glaring issues. In a few months, the first version of Subversion was released and it's been extremely popular among developers ever since.
As previously mentioned, Subversion is a centralized VCS. Clients can check out (make a local copy of) the repository on their local machines, and after making changes, they can check in (update the server with the changes) the changes to the server. As with any VCS, you can compare two versions, create a branch and merge it with the main stream, and when there is a conflict, resolve it.
Git on the other hand has been built from the ground up as a distributed version control system. The number of redundant copies of all the code, history and meta information is as large as the number of users. So even if the central repository is lost due to a system failure, all the data -- other than the last few changes that were not committed -- can be retrieved from any client machine. In a centralized VCS like Subversion, only the central repository has the complete history. Clients must communicate over the network to fetch the history of any file that they require. So, if the central system goes down you have to resort to the last backup of the server.
So, the biggest difference between Subversion and Git is that in Subversion only the central repository stores the complete history while in Git all clients have all the information. An immediate reaction might be to give a couple of extra points to Git because the chances of losing data are minimized, but it has its downsides too. Considering that the source code you store in Git is proprietary, you should secure it as much as possible. In a distributed system, it is extremely hard to secure your data as there are so many copies of it.
With Subversion, all the data must be written to, and is read from, the central server. Securing that server assures that your data is secure. To ensure the durability of the data, you can set up a systematic backup of the Subversion server.