Subversion vs. Git: Choosing the Right Open Source Version Control System
Platform Support: Advantage Subversion
As I mentioned earlier, one of the considerations of choosing a VCS is the operating system on which you need to access your data. While Subversion works well on all operating systems, Git doesn't play well with Windows. Windows lacks a good graphical application to access Git repositories, which has left Git popular primarily among Linux/UNIX users and some Mac users. In fact, only Linux-based projects such as the Linux Kernel, the Fedora project and WINE use Git.
Ease of Use with User Interfaces: Advantage Subversion
Currently Subversion has a wider range of user interface tools than Git. For example, Subversion plugins are available for most major IDEs on all platforms, as is a Windows Explorer shell extension and a number of native tools for Windows and Mac OS X.
Branch Handling: Advantage Git
One of the biggest advantages of a VCS is the ability to branch out from the main stream. In Git, branches are not a dirty word -- they are used often, several times a day by some developers. For every feature or bug fix, you create a new branch and after you are done, you merge the branches back painlessly. In Subversion, branching is easy but if you get into a conflict while merging, you're in trouble. You might need to manually merge the files that are conflicting.
Speed of Performance and Space Occupied: Advantage Git
When it comes to comparing the processing speeds and the space occupied by the meta information of the VCSs, Git wins hands down. In Git, because the entire repository is available locally to the user, the following actions are performed locally and there is no network latency:
- Viewing history of a file
- Performing a diff
- Obtaining another version of a file
- Merging branches
- Committing changes
The only operations that need a connection to the network are the
fetch operations. Compare this to Subversion, where every action is performed over the network.
The space requirements of Subversion also are very large when compared with Git's. Take for example the Mozilla project, which requires over 12GB in Subversion to store the 10-year history of the project source code. In Git, the same history is stored in 420MB -- a 30x reduction in space.
The reason for this huge difference is the way changes are stored in both systems. Git stores about 100 bytes of data in an index file for changes made to a file in the repository, while an Subversion repository stores two versions of each file; one for the user to actually work with and the other hidden in the
.svn/ directory to perform operations such as
If you have ever collaborated with other people on a project, then you are well aware of the frustrations of sharing files. Whether you email files to one another or upload them to a server, every so often you curse one of your team members because they overwrote a change that you made. The lines of code you wrote are gone -- buried for good. The simplest way to resolve this problem is to make sure that no two people are working on the same file at the time. As simple as that sounds, it can be quite a pain to enforce such a policy on a team. Enter version control systems.
In this article, I covered some of the key differences between the Git and Subversion version control systems. There are several others that you might want to consider before choosing one over the other. If you are not using any version control as yet, start using one immediately if not sooner. If you can't make up your mind about which one to go with, I suggest using Subversion because the learning curve is less steep.
Page 2 of 2