There are plenty of ways to start a fight in a bar full of passionate inebriated devs. One of the more effective methods is yelling out “How can you say SVN is better than Git?” (or vice versa) at a random dev in the crowd. Then sit back and watch mayhem ensue and put your money on the winner (if you’re the betting kind).
In reality, both SVN (Apache Subversion) and Git are effective and popular version control systems (VCS) that enable workflow and project management in software development. There are differences in both the overall approach and industry-recommended best practices. It’s up to each programmer (or development team leader) to pick the right versioning system for every project they work on. Believe it or not, but making the wrong decision can cost developers many hours of work, sweat and tears.
What is the difference, really? When should you pick which? Let’s start with reviewing the distinctions between Git and SVN.
Differences between Git and SVN
The main and perhaps best-known difference is in its core architecture. Git version control is distributed while SVN is centralized. However, that’s just the tip of the iceberg. Other variations in approach and functionality between the two are important to understand if you want to use either effectively.
| Git | SVN | |
| Server architecture | Installed locally and acts as both server and client. | Requires a centralized server and user client. |
| Revisioning | Git is an SCM (source code management) tool. As such, it does not have a global revision number feature. | SVN is a revision control system. As such, it features a global revision number. |
| Repository cloning | Yes | No |
| Storage format | Metadata | Files |
| Storage requirements | Limited capacity to handle large binary files. | Can handle large binary files in addition to code. |
| Branching | Branches are references to a certain commit. They can be created, deleted, and changed at any time without affecting other commits. | Branches are created as directories inside a repository and when the branch is ready, it is committed back to the trunk. |
| Access control & permissions | Assumes all contributors have the same permissions to the entire codebase. | Allows for granular permissions with read and write access controls per file level and per directory level. |
| Ease of use | Harder to learn | Easier to learn |
| Cryptographic hashing | To protect from repository corruption (due to network issues or disk failures) Git supports cryptographically hashed contents. | n/a |
| License | GNU (General public license) | Open source under the Apache License |
| Change tracking | Repository level | File level |
| Original developer | Linus Torvalds (developed for Linux kernel code control) | CollabNet, Inc |
Based on this comparison, we can pinpoint the advantages and disadvantages of each.
Advantages of SVN over Git
The general sentiment on the web leans toward Git as their go-to solution for version control in their projects. However, several noteworthy open source projects still opt for Subversion over Git (the WordPress codebase) with roughly 24% of projects on OpenHub using SVN. This is precisely the reason we picked to focus on the advantage of SVN over Git first.
Superior architecture performance
One thing that can be said in favor of centralized version control architecture like SVN is that it is efficient in handling network traffic and assuring synchronization between teams and developers.
When you work with SVN you only need to synchronize the differences between what you have locally and the latest on the server. This is much faster than with Git. Due to it being distributed, you have to download all changes, even if those changes add gigabytes of useless assets that have since been deleted from the branch.
This is wasteful, especially if you’re working on a crowded network and don’t feel like taking a nap while the repository syncs. More so if upon waking up you realize you downloaded gigabytes of a repository where the branch you checked out wasn’t even touched by anyone else.
Better handling of binary files
Perhaps the most inarguable advantage SVN has over Git is in how it handles binary files. The reason for this superiority is the support Subversion provides for the Lock-Modify-Unlock model. It is implemented in SVN using a lock command (svn:needs-lock property) while Git offers no exclusive file locking at all due to its distributed nature.
For enterprise projects with multiple non-mergeable binary assets in the codebase, this is a real deal-breaker and often the reason they choose to stick with SVN.
Usability and ease of use
This can be a topic for arguments, but many developers insist SVN is easier to learn and use than Git. Features are faster to add and the syntax is a lot cleaner by offering better abstraction capabilities.
Access control
The Git architecture assumes that everyone using it has the same permissions. Getting read and write access to the entire codebase in their own branch is matter of fact. In fact, it has no user permission designation of its own. While fully acceptable in the open source world, this approach can prove risky in an enterprise setting. In many cases confidential and proprietary information might be revealed to third-party contractors working on some portion of the code as a result of bad access control.
Not so with SVN, where granular path-based user permissions are built into the system allowing for tighter code security and control.
Advantages of Git over SVN
Some claim the main reason Git has become the default choice for many developers is actually GitHub and the ease with which it allows for the sharing of code. That in itself is not a reason to pick Git over SVN, but may shed light on why so many do.
Git popularity
A kind of chicken and egg dilemma concerning the superiority of Git unfolds. Is it really better or simply has better PR thanks to GitHub and the open source movement? Either way, it seems that all the cool kids are doing it and even the non-cool kids are catching up.
(Pretty much every dev on reddit ever)
Easier merging
Merging repositories is never easy, no matter what versioning architecture you use. That said, Git is a better architecture for merging repositories. This is simply because the ability to merge code from multiple contributors is the main focus of Git and the architecture was built to enable community collaboration.
Offline support
Imagine you’re on the road and a critical bug needs fixing. You sync your repository, code the fix while on a flight or at a conference and quickly push and commit. All good so far, but what happens if you find yourself offline? The distributed nature of Git ensures that code can be pushed and committed locally and independently of the main repository. This makes Git versioning not only lighter on network traffic, but also ensures independence from a centralized server which may or may not crash exactly when you need it.
Committing and submitting to versioning trends
There’s no argument that software versioning is important, and the main debate is over which architecture and approach is best and when.
With Git serving as a decentralized solution aimed at open source development and SVN still a favorite with enterprises, the debate is likely to continue for years to come. Odds are it will just become more vocal with representatives of systems like Mercurial, Bazaar as well as old players (CVS) and new (Microsoft Azure DevOps).
