[Total: 3    Average: 3.7/5]

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.

git vs subversion

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.

this is git meme

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.

when to install git flowchart

(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.

svn is down meme

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).

switching to git meme


Codota_Banner_JavaScript_1.1


About the author

Ilana is a content writer for the Codota.com blog

Leave a Reply