Can I use Subversion (svn)?
Our servers have the Subversion version control software installed. Technically advanced users can use Subversion with any of our Web hosting plans.
On this page:
- Running the Subversion command (svn)
- Where to place your repository
- Providing secure remote access to your repository
- What if I get errors about a “DB_VERSION_MISMATCH”?
Running the Subversion command (svn)
To run Subversion, first login at the command line shell, then type svn with the appropriate options. For example:
Where to place your repository
If you want to create a new Subversion repository, you should create it in your home directory (instead of your Web site directory) so that visitors to your Web site can’t simply download the raw repository files.
To see the path to your home directory, enter your domain name in the box at the top of this page.
Providing secure remote access to your repository
If you create a Subversion repository, you may want to provide secure access to yourself or other users in remote locations via the Internet. Subversion offers several different ways to do this.
One that you might read about uses WebDAV to offer access over HTTP. Unfortunately, due to security concerns, our servers don’t use the mod_dav module. That means you can’t use this method directly, although it’s possible to use CGI or PHP scripts that provide a view into the repository (such as ViewCVS).
By default, if you issue public keys to multiple people, subversion won’t automatically record separate usernames in the subversion logs. You can fix this by adding --tunnel-user=username as part of a “command” in the “authorized_keys” file you create on the server.
Here’s a simple example of what the “authorized_keys” file might look like for two keys issued to users named “charlotte” and “drake”:
command="svnserve -t --tunnel-user=charlotte" ssh-dss A0B1C2D3... command="svnserve -t --tunnel-user=drake" ssh-dss E4F58690...
In fact, adding a specific command to the “authorized_keys” file allows you to restrict and control the keys in other ways, ensuring that the people you issue the keys to can’t do anything except access the subversion repository. Here’s an example of a more extensive “authorized_keys” file:
command="svnserve -t --tunnel-user=charlotte -r /home/ex/example.com/svn",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding ssh-dss A0B1C2D3... command="svnserve -t --tunnel-user=drake -r /home/ex/example.com/svn",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding ssh-dss E4F58690...
This adds the -r command to specify the repository root directly. This makes it so that clients don’t need to (and can’t) specify a full path, allowing them to check it out with this simpler command:
svn co svn+ssh://firstname.lastname@example.org/newproject
It also adds several SSH options beginning with “no-port-forwarding” that prevent the key from being used to do anything other than running the “svnserve” command.
(Thanks to James Gardner for tips on the correct way to make svn+ssh handle multiple usernames.)
What if I get errors about a “DB_VERSION_MISMATCH”?
Sometimes, you might see an error message like this after the subversion software is upgraded:
svnadmin: DB_VERSION_MISMATCH: Database environment version mismatch
If this happens, you can usually fix it using the svnadmin recover ./ command in the project directory. Other more drastic solutions are also suggested by some people if that doesn’t work.