What Is SVN?
Before 2010, Apache Subversion - or SVN - was a very popular version control system. It was then that Git began to gain popularity. Because of Git’s continuing growth, and some more toilsome activities in the platform, SVN’s popularity is on the wane.
But there are still millions of lines stored in SVN. It even continues to be actively maintained, albeit by a small open source community. This blog post acts as a foundation on top of which you can build deeper knowledge. If you want to learn more about how to use and host SVN, check out our tutorial on how to host Subversion.
In the late 1990's CVS (Concurrent Versions System) was widely used in software development for both open source and commercial projects. However, CVS started to receive a lot of criticism and soon became substandard. For example, CVS had poor support for third party tools, and absolutely no support for http/https/ssh protocols. Thus, a better system was needed.
In 2000, SVN development began in earnest. The goal was to create a reasonably compatible successor to CVS. Interestingly, around the same time frame, many CVS users switched to Perforce Helix — to this day, we continue helping the remaining diehard CVS users with such migrations.
Even though SVN development was initiated in 2000, version 1.0 wasn't published until February 2004. It mimicked many of the features in CVS but also introduced new features that CVS was missing, such as atomic commands and the ability to rename and move versioned files.
SVN became an Apache project in November 2009 when it was accepted to the Apache Incubator. After SVN was introduced to the world, CVS adoption withered away and it has not released new versions since 2008.
SVN Is a Centralized Version Control System
Version control systems can be roughly divided into two categories: distributed version control systems (DVCS) and centralized version control systems (CVC). SVN falls into the latter category.
A centralized version control system means that the version history is stored in a central server. When a Developer wants to make changes to certain files, they get files from that central repository to their own computer. After the developer has made changes, they send the changed files back to the central repository.
Challenges with SVN
The most common complaint that developers voice about SVN is its tedious branching model. Branches allow you to work on multiple versions of your code simultaneously. In SVN, branches are created as directories inside the repository and this directory structure is the reason why developers are less than fond of Subversion's branching model.
Subversion's version 1.6 introduced a concept called tree conflicts. Tree conflicts are conflicts that are caused by changes in the directory structure, such as renaming or deleting files. Since changes in the directory structure are quite common, tree conflicts occur relatively often. Since SVN doesn’t allow you to commit your changes when there is a tree conflict, this obviously adds complexity to implementing a branching strategy in SVN.
Note: Helix Core offers an extremely powerful and far easier approach to branching called Streams, aka “branches with brains.”
SVN requires you to be connected to the central repository in order to commit. At this point, it is good to repeat the ancient version control adage: "Commit early, commit often." Keeping this wisdom in mind, it seems that using SVN without a connection to the central repository is pointless. For example, if you often code offline, during flights for example, remember that SVN doesn’t allow you to commit to the central repository before you restore your connection.
Merging is the other big problem that developers often complain about with SVN. If you are working with a history where a set of changes are made, and committed, then another change is made (i.e., linear), and committed, the merge will be easy. Things get complicated when you have two or more developers working on the same code base and you need to merge. In this case, SVN fails and causes the developers to resolve the conflicts manually, wasting many hours of developer time.
Git and other commercial VCS systems long ago overtook SVN in popularity. The reason SVN is still around is cost and inertia combined. Cost, because it is “free,” as in open source. Inertia, because once a large code base is built up, it’s very hard to switch VCS systems. SVN has been around since 2004, and the many organizations who adopted it have millions of lines of code sitting in it.
My goal with this blog post is to give you some context for you to understand what Subversion is and what it is used for. If you are a user of SVN, or know someone who is, we have solutions! We can offer unparalleled flexibility in how to move forward with your enterprise code base. If you need a cloud solution to keep your code in SVN; or are transitioning to Git, either cloud or on premises; or want an globally scalable, enterprise server solution that can handle very large files, check out Helix TeamHub and Helix TeamHub Enterprise.