What is Subversion?

Subversion is a Source Code Management (SCM), a tool for software developers which supports collaborative development of software within a team, and the tracking of changes to software source code over time.

Subversion is used by developers, and advanced users who need the very latest changes to the software (before releases occur). Software users generally do not need Subversion; typically they will download official file releases made available by the project instead.

Developers should familiarize themselves with Subversion by reading Version Control with Subversion.

Modern SCM facilities

Here's a nice writeup of why you should consider using a Distributed Version Control System (DVCS), and a comparison of the major DVCSs:

Features provides the following features in its Subversion offering:

  • All standard features of Subversion 1.6.x are supported.
  • Developer (read-write) access is provided via svn+ssh and https. Non-developers with SourceForge accounts can also use these protocols as read-only.
  • Anonymous (read-only) access is provided via svn and http.
  • Several Subversion clients are supported, including:
    • TortoiseSVN (MS Windows).
    • The official SVN client (MS Windows, Mac OS X, Linux, BSD).
  • Repositories may be viewed via web browser using the Allura code browser.
  • Repository access may be granted or revoked from a developer using the Project Admin interface.

  • Service usage is not restricted by quotas.


Creating a repository

Subversion service can be selected to be installed at project creation time. It can also be added to an existing project as follows:

Login as a project administrator and

  • Click the "Add New..." link in the project menu bar
  • Click on "SVN".
  • Select a name for the label (this will determine the title of the link in the project navigation)
  • Select a Url Path (this will affect the URL for your repository)

Follow the instructions on the SVN repo page to create the recommended branch/tags/trunk format, or import existing files.


The following options are available, under the "Admin" section in the left sidebar of your repository:

Viewable Files

Specify here a space delimited list of filename extensions that should be viewable in the browser (ie., plain-text files)

Refresh Repository

The code browser typically will be refreshed automatically when there's a new change, but it can also be manually refreshed if necessary


Specific permissions for the repository can be configured here. Fine-grained permissions controls are not supported (e.g. restrict access by specific paths within a repository), if that sort of access control is required, consider creating multiple repositories with different permissions.


This will delete the repository on our servers, note that while this is normally very quick, there is occasionally a delay in removal.

Checkout URL

By default the code browser will include a command for users to checkout the trunk of the repository. If a different default checkout location is preferred, this can be specified here.

Developer Access (Read/Write)

The standard way to modify the contents of your repository is using a Subversion client as detailed in Version Control with Subversion.

Read/Write access via svn+ssh

svn+ssh will provide faster performance than https. This should be used whenever possible.

To access a Subversion repository over svn+ssh, configure your Subversion client as follows (replace PROJECTNAME with the UNIX group name of the project, and USERNAME with your username):

Port: 22
Protocol: SVN + SSH
Repository Path: /p/PROJECTNAME/code

For clients that use a URL string:


Read/Write access via https

Access over https will not perform as well as svn+ssh, so it should only be used if access using svn+ssh is problematic (eg. if ssh port 22 is blocked).

It is also possible to perform anonymous read operations over https. A username and password is only required for write operations.

To access a Subversion repository over https, configure your Subversion client as follows (replace PROJECTNAME with the UNIX group name of the project):

Port: 443
Protocol: HTTPS

For clients that use a URL string:

Anonymous Access (Read-only)

https as detailed above can also be used for read-only access. In addition, you may also use the svn and http protocols with the same URLs.

For example:



No username and password will be requested when performing read operations over the svn, http, and https protocols.

When performing write operations, you will be prompted for your username and password. To perform write operations, your project administrator must have granted you write access to the repository.

Server Certificate Verification Failed

Subversion users accessing their repository over https may occasionally produce an error indicating that the SSL certificate issuer isn't trusted, giving you an option to accept the certificate:

Error validating server certificate for ''
- The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!
Certificate information:
- Hostname: *
- Valid: from Tue, 09 Oct 2007 13:15:07 GMT until Mon, 08 Dec 2008 14:15:07 GMT
- Issuer: Equifax Secure Certificate Authority, Equifax, US
- Fingerprint: fb:75:6c:40:58:ae:21:8c:63:dd:1b:7b:6a:7d:bb:8c:74:36:e7:8a
(R)eject, accept (t)emporarily or accept (p)ermanently? p

This typically happens during your first Subversion operation against our servers or when we replace the SSL certificate with a new one.

When you receive this error, we encourage you to validate that the server is the correct server by putting your checkout URL into a trusted web browser (i.e.

You may then check to make sure your browser accepts the certificate. If it does, you can trust the server much like you would any other HTTPS site, like banks, etc.

Once validated you should go back to your Subversion request and tell the client to permanently store the SSL certificate locally so you won't be prompted again until we update our certificate next.

Accessing the repository via the shell

Direct access to the server-side repository is also available via [SSH], when logged into the shell, it will be available at:


Note that the directory is mounted during the shell creation, if you create a new repository while an existing shell session is still active, use the shutdown command on the shell and start a new session.


Direct access to the repository can be used to install custom svn hooks server-side.

Note however, that a post-commit hook is used for site-integration, if this hook is changed, the code browser view may not longer automatically update. Instead, you should save any post-commit hook as post-commit-user instead, and it will be called by the default post-commit hook.

If you need to re-create the default post-commit hook, the template for that is:

# The following is required for site integration, do not remove/modify.
# Place user hook code in post-commit-user and it will be called from here.
curl -s

DIR="$(dirname "${BASH_SOURCE[0]}")"
if [ -x $DIR/post-commit-user ]; then  exec $DIR/post-commit-user "$@"

Backups performs routine backups for all of our servers and will restore from these backups in the event of catastrophic server failure. We encourage projects to make their own backups of repository data as that data restore can be performed by the project in the event of accidental data destruction by a member of the project team.

Backups of a SVN repository may be made using rsync.

Example (replace PROJECTNAME with the UNIX group name of your project, and REPOSITORY with the repo name):

$ rsync -av .


Community Docs: TortoiseSVN
Documentation: Docs Home
Documentation: SCM
Documentation: SSH
Documentation: ToC
Documentation: TortoiseSVN
Site Support: #3487
Site Support: #8840