Using Subversion

Subversion is a centralized software versioning and a revision control system. You can use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation.

This free book is a good place to start.

We recently migrated many of our projects to our GitLab server, so you might want to have a look over there.

Accessing repositories with your client

The location for a repository is So you can check it out with

svn co

Committing and updating work just like with any other subversion repository.

Browsing repositories

Just go to the repository location with your webbrowser. Or, if your repository is hooked up to one of the Trac environments, you can use the fancy Trac browser from there.

Graphical clients

Besides the standard Subversion command line client, there are also some graphical clients which you might find easier to work with. For Windows, there is TortoiseSVN and for Linux/Gnome there is RabbitVCS. Both are extensions to the normal file browser (Windows Explorer on Windows, Nautilus on Linux/Gnome) and both websites have screenshots.

GitHub mirrors

See these notes for how to setup a Git mirror of a Subversion repository on GitHub.

Subversion best practices

Repository layout

Use a standard repository layout, so have trunk, branches, and tags directories in the repository root.

# Have an empty repository created by the server admin called `my-project`
svn mkdir -m 'Create branches dir'
svn mkdir -m 'Create tags dir'
svn mkdir -m 'Create trunk dir'

Working copies

Checkout your working copy from a specific branch or from trunk (and use svn switch to change branch), don't checkout from the project root.

svn checkout my-project
cd my-project
svn switch


Tag your project versions. Never ever commit to a tag.

svn cp -m 'Tag 2.0.1'

Update often

At the start of every work day, and more often if team members are working on the project, update your working copy.

svn update

Commit often

Commit frequently, don't hold back uncommitted code on your local machine for days.

svn commit -m 'Add some boring feature'

Logical changesets

Commit logical changesets. A commit should reflect a single purpose, such as a the addition of a new feature or a bug fix. Don't mix unrelated changes, and don't mix code formatting changes with other changes.

Commit messages

Use descriptive and informative commit messages.

svn commit -m 'Make reference file loading by gene name case insensitive'


If your project has a Trac installation, use its ticketing system and create two-way links between Subversion changesets and Trac tickets. For example, use #NUMBER in your commit message to refer to a Trac ticket and use rNUMBER in ticket comments to refer to a Subversion changeset (example).

svn commit -m 'Unit tests for issue #172'

Ignore list

Files that can be generated from other source files (e.g. compiled binaries, LaTeX pdf results, etc) should not be tracked by Subversion. Add such files to the `svn:ignore` property.

svn propedit svn:ignore .
# Editor opens, add one ignore pattern per line, for example:
#     *.pdf
#     *.pyc

Sensitive information

Use the following pattern for configuration files. Let's say contains sensitive information, such as a database password. Have a copy of the file named tracked by Subversion, with the sensitive information taken out. Add to the svn:ignore property. In your product documentation, explain that users need to copy to and add the missing information.

svn add
svn propedit svn:ignore .
#     *.pdf
#     *.pyc

Trunk policy

Establish a policy for trunk and stick to it. One example might be, "trunk must always build without errors", or "trunk must always pass all unit tests".

More info

Migration from Europium

If you have an existing checkout of a repository from its old location on the Europium server, you can update it with the new location without having to do a complete new checkout.

Execute the following from the root of the checkout:

svn switch --relocate \

Check if the location is updated correctly by running svn info.

Please note that the configuration on the new server is such that you have just one username/password pair to access all your repository (so if you previously had multiple passwords, now one of them is valid for all your repositories — just try to see which one).

The following is a list of migrated repositories, together with their old and new locations.

Last modified 5 years ago Last modified on Nov 29, 2013 2:49:51 PM