Subversion Source Control for game development

This is part of a series of posts on source control for game development. Read more in the Blog.

We couldn't reach the end of this series without talking about a source control giant, I'm talking of course about Subversion or SVN for short.

Every programmer should have heard of Subversion. Its massive popularity from the 2000s until today has only been outshined by Git fairly recently. In the games industry, SVN remains a very popular choice due to being free and implementing the file-based source control model which maps so well to our needs, as outlined in the previous articles. While not a common choice in larger studios, smaller ones and indie teams have long been using SVN as their backbone and for good reason.

Personally, I haven't used SVN since my early programming days, and never in my professional career. This article was a good opportunity to get familiar with it again and see how it competes against the other solutions we have studied so far.

So, is SVN a good source control solution for game development? Let's dig in!

Background and History

Subversion was started in 2000 as a replacement and improvement over CVS, the most popular version control at the time. The main goal in designing Subversion wasn't to reinvent the wheel or a new source control model but to have a better CVS, without the bugs and the features deemed unnecessary or badly designed.

Subversion has since then become a pillar of the software development world, overtaking CVS and becoming the standard for many years, both in the open-source communities and in the enterprise world. Subversion 1.5, in particular, was a major release that introduced highly needed features, most notably automated merge-tracking which is seen today as essential in a source control solution, as well as mirroring capabilities.

In 2010, Subversion became part of the Apache Software Foundation, one if not the most well-known organization maintaining large open-source projects. Apache now oversees the ongoing development and distribution of the rebranded Apache Subversion and is still looking for contributors to the project, in true open-source fashion. Recently, Subversion celebrated its 20 years of existence and is arguably still the most widely used source control solution today.

While it has certainly lost some of its popularity with more recent open-source projects in the age of GitHub, Subversion is used by many large open-source projects and in many organizations. Subversion doesn't benefit from a large platform such as GitHub, but it remains a robust and proven solution. Existing projects and organizations may not want to pay the cost of migrating, especially when the development community at large becomes more aware of the limitations of Git and DVCS they may have to contend with.

Features

The official website lists the main features of SVN. Here we will go through what is relevant for us.

Centralized source control

SVN was designed as an improvement over CVS, which was centralized version control. Even though distributed version control existed at the time, a centralized model appears logical and simpler. Even in open-source projects, there is a central or "blessed" repository where the official releases emanate from. In enterprise projects, a centralized repository allows for better access control over the intellectual property stored in the version control system.

The centralized is generally the way game development teams collaborate on game projects. This implies that, in order to share changes to others, you need to be connected to the central server. This should not be an issue in our day and age, but it does mean that you cannot easily work offline and keep a local version history. As we will see later, there are in fact workarounds to this issue.

File-based model

SVN uses a traditional file-based model to track changes. Each object has a revision number, and each change is tracked by a globally unique incrementing number. This is very similar to other version control systems such as Perforce, and is very easy to follow and understand, especially in comparison to Git's SHA hash-based revision identifiers.

There are notable features of SVN's source control model that aren't commonly found in other. Directories are versioned as first-class objects, in the same way files are. Properties in the form of key-value pairs are versioned with each object (file or directory), which allows you to embed extra information, and potentially has creative uses.

Branching is done through the "copy" operation. This can sound strange at first, but a branch is, in fact, a copy of the entire repository in another directory. This is how most older source control systems operate with branches. Fortunately, there are series of commands that allow you to treat branches the same way you would in Git, and not have to actually maintain two directories with two versions of the project on your own machine. Internally, branches are managed using a copy-on-write mechanism, so branches are not as costly as they may seem, and the cost of branching does not increase with the size of the data in the repository.

Still, branching and merging is not as simple an operation as you may have gotten used to with Git. More importantly, branching is a server-side operation due to the centralized model of SVN. This means branches are visible to all users, and for that reason, managing branches is reserved for privileged users or administrators of larger repositories. Using feature branches for small development is usually not recommended, instead, you may use the shelving feature, which is similar to Git's stash.

SVN has an interesting feature in the form of properties. Properties are key-value pairs that can be attached to any SVN object, such as a file, directory, or revision. SVN itself uses properties to implement some of its advanced behaviors and features, for instance, file-locking. You may also creatively leverage properties for anything required in your workflow, such as tagging certain files or using it for automation.

User experience

Setup and administration

Setting up SVN can be challenging for non-technical users. The website and the documentation definitely have this old-school open-source look and feel, which could deter some people. The most complete documentation comes in the form of a free book, affectionately known as The Red Book, which is curated and kept up to date by the SVN community. You can consult the HTML version directly on its website, and we will refer to it throughout this article.

The first barrier of entry is that the Apache Foundation does not distribute binaries for subversion. You must download the sources and compile them yourself. They do, however, reference trusted sources of binary packages for you to download the version that matches your OS. For most of us, this means Windows, and I'll recommend using Tortoise SVN which also brings a very practical Windows Explorer contextual menu extension and a graphical user interface.

While installing Tortoise SVN, don't forget to install the command-line tools. Without those, you won't really have SVN installed.

When you first create a SVN repository using Tortoise SVN, you will be asked if you want to use the default folder structure. This creates directories for trunk, tags, and branches which are pretty self-explanatory. You should use the standard folder structure to start with, as most of the tooling around SVN is configured to handle these by default. Of course, it is up to you to decide how you want to structure your repository, and where you want to store your branches. SVN offers you all the flexibility you need through the copy command, and those folders are merely a convention for the users to follow.

Command-line

SVN's command line uses terms and verbs that have come to be the standard vocabulary when talking about source control, and are understood by most. Most of the semantics we use for source control nowadays can be traced back to historical software, notably CVS, from which SVN takes most of its roots. This means SVN's command line is intuitive and easily understood, unlike Git's which introduces many new terms and confusing mechanics.

All of the commands are well documented in the Red Book, and for the most part, I didn't have to consult the documentation much when operating on them. To get started quickly, you can learn the basics in a few minutes on the official SVN website.

All of the command-line output is designed both for human readability and for parsing by scripts and automation tools. On top of that, API bindings to several popular programming languages allow users to interoperate with SVN more efficiently and without having to start multiple processes and parse outputs.

Overall, the command line takes some time to learn but it is relatively straightforward. The commands are single purpose and with a wealth of options, and the mental model of the source control repository is very simple to follow. Some commands have several logical (or funny) aliases for convenience, so you should feel at home quickly no matter what other source control you may be used to.

Graphical User Interface

The Apache Subversion project does not provide, maintain or endorse any Graphical User Interface. As is true with everything SVN, you will have to find your own tools to attach to the version control core. You can find a list of SVN clients on Wikipedia.

In the context of writing this article, I have tried two popular SVN clients on Windows. They both provide graphical tools as well as a Windows Explorer contextual menu integration.

Tortoise SVN

I've already talked about Tortoise SVN before in the setup guide. Tortoise SVN has been popular for as long as I can remember and is fully free and open-source, released under GPL license.

The main way to interact with Tortoise SVN is through the contextual menu integration. Right-click on any file or folder and the Tortoise SVN menu offers pretty much every possible action.

Unfortunately, there is no Tortoise SVN integrated tool. Everything is done through the windows explorers and popup dialogs. Personally, I think this is a worse user experience, as I often want to see an overview of my repositories and rapidly get information over many things in my repository. On top of that, not all of the dialogs are created equal. They can differ in style and useability, and some are clearly more polished than others. For instance, the revision graph view could be made much more compact and user-friendly. Still, Tortoise SVN is very useable in its current form and will continue to be the workhorse of many developers.

SmartSVN

SmartSVN is another Graphical User Interface that caught my eye. It seems to be from the same developers as SmartGit, a popular Git client.

SmartSVN has a free version and a paid version. The free version contains only a subset of the features, and obviously the most advanced operations are left out.

While SmartSVN also provides a contextual menu integration, it presents itself first and foremost as a standalone tool. Using SmartSVN feels very familiar coming from Perforce. The main view is a repository view where you can browse for all files and see their status. You can use the toolbar to perform all the main operations, such as Adding and Removing files, Updating, and Committing.

You can browse the full list of features on the SmartSVN website. There are important features only present in the paid version of SmartSVN:

• Changesets, allowing one to separate modified files in several commits.
• Merge and conflict resolution. Alternative and probably better tools are readily available for this.
• Revision Graph, very useful to visualize changes of a file through branching and merging.
• JIRA Integration, often useful in professional projects.

The user experience of SmartSVN is, in my personal opinion, much better than that of Tortoise SVN, and the price could be well worth it. Alternatively, I'd consider using the free version alongside Tortoise SVN, command-line, as well as other tools. The paid version of SmartSVN seems to be the most advanced and well-integrated SVN client available at this time.

Code review tool

SVN does not come out of the box with a code review tool. There are several third-party options to choose from, some are free, and some others come at a premium.

Out of all the tools listed, I would recommend looking at:

• Review Board, free and open-source. While lacking in features compared to paid competitors, it's done the job for many companies and I've used it myself professionally.
• Collaborator, probably my favorite code review tool, but the price is steep.

Diff and Merge tools

SVN does not provide Diff or Merge tools out of the box either, outside of the command-line utilities.

SVN can, fortunately, be configured to use an external diff tool. You are free to choose yet again from a variety of options, free and paid. For those of you looking, here are some to consider:

• Meld, free and open-source, written in python. Well featured but sometimes slow.
• P4Merge is actually free, and this has been my workhorse for my entire career.
• SemanticMerge from the company behind PlasticSCM. A paid solution, but with unique features. I went in more detail about SemanticMerge in my PlasticSCM breakdown.
• Beyond Compare, a popular paid tool. I've also used this and enjoyed it, but I did not see enough benefit to warrant buying a license for myself.

Useability for game development

Handling large projects

SVN has proven time and time again to be dependable for game projects. Many independent studios have chosen SVN for their source control because of its price and file-based model. Therefore, we can safely say that by using SVN, you cannot go entirely wrong.

However, it is also known that SVN has performance issues on larger repositories, and generally, this is the main argument its competitors, namely Perforce and PlasticSCM, use as the first real reason to consider switching. It's going to be very hard for me to evaluate SVN with a very large project that would recreate the enterprise conditions, so I can only take the testimonies at face value by saying: SVN is generally less performant than Perforce and PlasticSCM.

Still, SVN handles binary files very well and its model should scale relatively well according to our use cases. Two lines on the features page stand out:

• Binary files handled efficiently. Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions.
• Costs are proportional to change size, not data size. In general, the time required for a Subversion operation is proportional to the size of the changes resulting from that operation, not to the absolute size of the project in which the changes are taking place.

This should put you at ease when it comes to managing the binary files your game project will be filled with.

SVN can be brought up to an enterprise level by leveraging several features and extensions, some built-in and some using third-party software and services. SVN has been successfully used in enterprise scenarios for many years, in fact, the debate is still ongoing as to whether Git is really an improvement over SVN in many cases, and I tend to agree with some of the points made.

VisualSVN Server seems to be the most common server on offer, and it comes with multiple features useful for enterprises:

• ActiveDirectory / LDAP integration, which enables Access Control features
• For globally distributed teams, offers the ability to replicate your repository on remote sites in write mode
• Backup and restore policy
• Logging and auditing features

VisualSVN Server is unfortunately not free, though it seems to be the best enterprise SVN server available. Some of these features can be solved through other means, such as using svnsync to create read-only copies of your repository, but then you'll have to manage them yourself.

SVN also contains all the more advanced source control features you might need, for instance, you'll find an equivalent to Git's submodules in the Externals feature of SVN. This really shines when you are managing multiple projects at once.

There are also some more exotic tools that I found when doing my research. For example, SVK is an SVN client that adds more operations and allows for offline and decentralized workflow. I can't vouch for it as I haven't used it, but this goes to show that there is probably a solution out there for most of your SVN problems.

File-locking

File-locking is fully supported by SVN. On top of the basic locking and unlocking features, SVN allows for a user to leave a message to explain why they locked a particular file, which is a surprisingly simple and useful addition that I haven't seen elsewhere.

There are also ways to override locks when necessary. Of course, there are traditional administrator commands, but on top of that, SVN allows users to break and steal locks from other users. Of course, this is configurable and you may allow only privileged users to break locks instead of everyone. This can become useful when someone goes away for some reason while having the lock on a file, and you don't always have an administrator available to help.

Finally, files can be tagged to require a lock, and SVN will automatically set the file mode to read-only when you don't have the lock. This works beautifully and avoids making mistakes and wasting time.

Ecosystem

SVN has a long history and was very popular before the age of Git. Therefore, we should expect a great ecosystem that includes everything we need.

Integrations

SVN is well integrated with most typical development tools, such as IDEs and Continuous Integration tools. Here are some of the most useful for us:

• Visual Studio, the IDE you're most likely to use, has an up to date SVN integration.
• Jenkins and I'd expect most Continuous Integration tools.
• Unreal Engine has first-class support for SVN, and the plugin is available out of the box when downloading the engine. Sadly, Unity does not.
• Project management and bug tracking tools such as Jira also often support an SVN integration.
• Communication apps such as Slack or MS Teams.

SVN is almost as well supported if not better than Git. Of course, most modern software will aim to interoperate with Git before SVN these days, but there is more than enough to be happy with and to satisfy all of our workflow needs.

Interoperability

SVN used to be the ubiquitous source control, which makes it a prime target for competitors trying to convert users. Here are a few bridges between SVN and other source control software:

• git-svn, an officially supported bidirectional integration between Git and SVN. You're most likely going to need this even if you use SVN as your primary repository since it's likely that you will need to collaborate with third-parties using GitHub.
• HgSubversion, a bidirectional bridge with Mercurial.
• Perforce provides a migration guide and toolkit
• PlasticSCM recommends using git-svn and their own Git interoperability tools

Hosting

SVN has been around for a long time, and it is not surprising to see many providers of cloud hosting. Unfortunately, there isn't a hugely popular website setting the standard, so we'll have to dig ourselves to find the best options. Fortunately, Wikipedia contains a good overview of source control hosting we can start from.

Here are some of the notable providers:

• SourceForge, one of the most well-known hosting providers for open-source projects. SourceForge offers both the project management backend and provides a landing and download page for the software for its users.
• Assembla, which is also the sole provider of cloud Perforce hosting, and can be considered a reliable hosting provider. The lower tier starts at $9.16/user/month for up to 5 users and 5GB of storage. Above this threshold, the price goes to $14.67/user/month with "500gb+" storage included.
• Helix TeamHub by Perforce. Free up to 5 users and up to 1Gb storage. The paid tier comes at a very low $19/user/year, but still with a relatively limited storage capacity.
• Cloudforge, for $2/user/month, but the storage capacity is tied to the number of users. Higher tiers allow for more storage.
• Phabricator, an open-source hosting provider platform. While it is $20/user/month for the cloud option, Phabricator is a very good choice to host internally to manage your projects and repositories.
• RhodeCode provides enterprise solutions starting at $8/user/month, with increasing costs depending on the hardware and storage capacity chosen.

Most of these providers have been active for a long time, and it also shows on their website and their offers. On this front, SVN does not enjoy the modern luxury that Git hosting has become. The user experience and features of the above are most likely not up to par. More importantly, neither is the pricing model, especially in light of GitHub's recent pricing updates.

That being said, this is not such a big issue if you're considering SVN for your game development project. Any of these solutions will give you a server with high availability, and that is all you really need. You can use other tools for project management if your hosting provider's platform does not meet your needs. For smaller teams, you should be fine using those.

Pricing

SVN is free and open-source. However, source control for game development can never be completely free.

You will have to host your project in a shared location, either on the cloud or on-premises. We touched on the cost of cloud hosting before. Of course, you may host SVN yourself on your own hardware, or using public cloud instances. The costs and maintenance involved can vary widely to be as expensive as you make it: hardware purchase and maintenance costs, backup and restore strategy, network infrastructure, and so on... It is up to you to find the best solution for your team size, configuration, and most importantly, your budget.

In comparison to its competitors in our study, SVN is the second cheapest source control for game development. Its cloud hosting options are more expensive than Git, but there are no license costs of any kind. For the budget game developer, and considering the technical limitations of Git for game development, it appears to be the cheapest, and therefore the best choice.

Conclusion

Subversion is a robust and proven software. It was once the dominant source control solution and remains very competitive to this day. It is free and open-source, still being maintained, and has an active ecosystem, even in the age of Git. I would love for SVN to have a more visible roadmap, as the current one doesn't provide much information. Some versions of SVN benefit from Long Term Support which is good news and a strong guarantee for you if you're starting today.

While the bulk of the software industry has moved on to the next shiny thing, SVN remains a very relevant source control for game development. Why? Its file-based model is exactly what we need, and its handling of binary files is only surpassed by expensive proprietary software such as Perforce or Plastic SCM.

SVN's flaws come mostly from its open-source legacy and its age. Much like Git, SVN is only the command-line core of the source control and does not provide the full package of tools and integrations a user will need on a day-to-day basis. Unlike Git, the tools and web services that are part of the SVN ecosystem aren't up to the latest standards of user experience and design. You will, therefore, have to research and choose for yourself which tools to use on top of SVN, and you may allow each of your team members to go with what fits them best.

But this is mostly cosmetic, and while cosmetics matter very much to some, it should not be the most important aspect for you if you're in business for a source control solution for your game development project. Price and features are the primary axes of comparison, and on that front, SVN is by far a better solution than Git. If your budget allows, then probably PlasticSCM or Perforce would offer either more features or more performance. For independent developers, it is often not worth the cost, and it explains why SVN has found a niche there.

We're reaching the end of the in-depth studies in this series. In the final article, I will try to reach a conclusion from all the learnings, and a summary for those of you who are still (but rightfully) confused.