What Is SVN?
What Is Subversion?
Before 2010, Apache Subversion — or SVN — was one of the most popular version control systems. Now, SVN’s popularity is on the wane, but there are still millions of lines stored in it. It even continues to be actively maintained, albeit by a small open source community.
The Birth of SVN
In the late 1990's Concurrent Versions System (or CVS) was widely used in software development for open source and commercial projects. However, CVS started receiving criticism. It had poor support for third-party tools and absolutely no support for http/https/ssh protocols. It soon became substandard, and a better system was needed.
In 2000, SVN development began in earnest. The goal was to create a compatible successor to CVS.
Even though SVN development started in 2000, version 1.0 wasn't published until February 2004. It mimicked many of the features in CVS, but it also introduced new features that CVS was missing. Users could now do atomic commands and had the ability to rename and move versioned files.
SVN became an Apache project in November 2009 when it was accepted to the Apache Incubator. And after SVN was introduced to the world, CVS adoption withered away.
How Does Subversion Work?
SVN originally was designed as a command line interface. This means you would open your Terminal and type text commands.
For Subversion to work, the SVN setup needs two main elements:
- The server, which has all versions of all source files
- A local copy of the files, which is on your computer
The files on your computer are called working files. These are the files in which each user makes edits. Then, users commit their changes to the SVN server, which is also called the repository.
Each time a user commits a change, SVN manages and records it by creating a new version. Like most version control systems, users typically work with the most recent version. But if an older version is needed, you can revert to an earlier version.
What Is SVN Server?
(AKA: What Is a Subversion Server?)
An SVN server has all the source files, as well as all the versions of the files. In the SVN world, the server is called the repository. So, an SVN server and an SVN repository are the same thing.
The local copy of the files (which are stored on your computer) is called a working copy.
Is SVN Distributed or Centralized?
Version control systems can be roughly divided into two categories: distributed version control systems (DVCS) and centralized version control systems (CVCS). SVN is a centralized version control system.
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 pull 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
SVN Has a Tedious Branching Model
The most common complaint 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. Many developers dislike this directory structure. But the challenges don’t stop there.
SVN version 1.6 introduced a concept called tree conflicts. Tree conflicts are conflicts caused by changes in the directory structure, and they occur often. Since SVN doesn’t allow you to commit your changes when there’s a tree conflict, this adds complexity to implementing a branching strategy in SVN.
SVN Requires You to Be Connected to the Central Repo
In order to commit changes, SVN requires that you’re connected to the central repository.
At this point, it’s good to repeat the ancient version control adage: "Commit early; commit often."
With this wisdom in mind, using SVN without a connection to the central repo is pointless. For example, if you code offline – during flights, for example – SVN doesn’t let you to commit to the central repo before you restore your connection.
SVN Requires You to Resolve Conflicts Manually
Merging is the other big problem that developers often complain about with SVN. If you’re 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 the developers need to resolve the conflicts manually, which wastes hours of developer time.
Why SVN Is Used
Git and other commercial version control systems overtook SVN in popularity years ago. But SVN is still around for two reasons: cost and inertia.
- Cost: SVN is open source, which means it’s “free.” Learn more about the real cost of SVN.
- Inertia: Once a large code base is built up, it’s can be hard to switch VCS. SVN has been around since 2004, and the organizations who adopted it have millions of lines of code in it.
If you’ve outgrown SVN, Perforce has enterprise version control software that lets you scale without limits. Helix Core is perfect for collaboration, scalability, and flexibility. Try the full version of Helix Core. It’s free for up to 5 users and 20 workspaces.