For years, Apache Subversion - or SVN - was the most popular version control system. Then came 2010, and Git started to gain popularity on SVN's expense. The reason for this is most likely that the open source community found Git more lucrative than SVN. Despite Git's ongoing winning streak, Subversion is still widely used and has a solid user base.
In this blog post, I'm not going to cover all of the features SVN has, or how its command syntax works. If you want to learn to use SVN, you should complete this Subversion tutorial. This blog post acts as a foundation on top of which you can build more deeper knowledge.
Around late 1990's CVS (Concurrent Versions System) was very widely used in software development for both open source and commercial projects. However, CVS had started to receive a lot of criticism and was considered not to meet the standards of the era. For example, CVS had poor support for third party tools, and it had no support for http/https/ssh protocols. So, a better system was needed.
In 2000, Collabnet started to develop a version control system in order to replace CVS. As a result, Subversion was introduced. It covered pretty much all the features in CVS but also introduced new features that CVS was missing, such as atomic commands and possibility to rename and move versioned files.
Even though SVN was initiated already in 2000, version 1.0 wasn't published until February 2004. SVN became an Apache project in November 2009 when it was accepted to the Apache Incubator.
After SVN was introduced to the world, CVS withered away quite fast and it has not published new versions since 2008. SVN is still in development and a new version of it is expected on 2017.
SVN is a centralized version control system
Basically, software developers use version control for storing and tracking changes in different types of files, such as source code and documentation. This enables multiple developers to work effectively on the same codebase without messing up each others' work. If somebody makes a mistake or something unexpected happens, version control ensures that the latest working version of the code can be restored.
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.
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 check out the files from the central repository to their own computer. After the developer has made changes, they commit the changes back to the central repository. The complete revision history in the repository is not copied to the developer's computer, as it would be in a distributed version control system.
Common problems with SVN
The most common complaint that developers have towards SVN is its tedious branching model. A little explanation for you less experienced version control users might be in place: 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 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. This obviously adds some complexity to using branches in SVN because SVN doesn't allow you to commit your changes if there is a tree conflict. In comparison, Git's branches are just references to certain commits in history, which is a lot more lightweight approach.
SVN's centralized nature has also some shortcomings. Since the version history is stored on a central server, you pretty much have a classic case of "all eggs in one basket". If the central server goes down or is maintained, no commits or checkouts can be done. What is even worse is that if the server breaks down beyond repair, you'll lose the history altogether. Unless you have proper backups in place. Therefore, remember to take constant backups of your repositories, store them on a separate server, and make sure that they work!
In addition, a centralized version control system requires you to be connected to the central repository in order to commit. At this point, it is good to repeat the ancient wisdom of version control: "Commit early, commit often". Keeping this wisdom in mind, it seems that using SVN without a connection to the central repository is kind of pointless. For example, if you often code during flights, remember that SVN will not allow you to make smaller saves (commits) to the central repository before you have restored the connection. In distributed version control systems, no connection is needed for the majority of actions. This also makes most of the actions on distributed systems a bit faster.
This may seem a bit contradictory, but SVN's centralized nature is not only a threat to the data security. Security is actually one of the greatest benefits of SVN.
As the version history is stored in a central server in SVN, you can argue that it is more secure than on distributed systems. The reason for this is that the history cannot be changed without access to the server. Thus, a developer working on their own local working copy cannot do damage to the version history by accident.
Another benefit of Subversion is that it, by default, allows you to manage read and write permissions on a repository and even on a file level out of the box. This gives you an extra level of security since you have the control on who can do what on your SVN repositories. With proper tools, you can do this also for Git and Mercurial. For example, with Deveo you can manage access rights per project and even per repository and branch level.
SVN works also well with large files. The usual problem with adding large files to version control systems is that the version history of the large files tends to consume a lot of disk space. Now, in distributed version control systems - like Git and Mercurial - the whole version history is downloaded to the developer's computer when they clone the repository. As a result, also the complete version history of the large files follows and makes the cloning slower and slower over time as the versions accumulate. Of course, you can use workarounds like Git LFS or similar in distributed systems.
SVN's workflow works better by default for versioning large files. Since a developer checks out only the latest changes in the repository, the complete version history is not copied to the developer's computer. Therefore, the downloaded files are much smaller than they would be if they included the complete version history of the large files.
Are you interested in a more detailed comparison of Git and Subversion? Read more on Git vs SVN.
As I mentioned earlier, the open source community and modern development teams have been favouring Git over SVN during the last 3-5 years. However, Subversion is still widely used, especially in the corporate world. The obvious reason for this is that SVN has been around since 2004, and many organisations that adopted it already then and are still using it.
Due to SVN's suitability for storing large files, many of the SVN users work with graphical assets, videos, and similar. Good examples of this are the game development industry or web design. SVN is also fairly simple to learn, so also non-developers can grasp it quite easily, making it a better fit for teams with different levels of technical know-how.
My goal with this blog post was to give you some context for you to understand what Subversion is and what it is used for. If you are interested in learning more, I suggest that you visit this guide on Subversion. And when you are ready to set up your first repositories, Deveo offers free hosting for Subversion in the cloud.