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 website directory) so that visitors to your website 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 “.ssh/authorized_keys” file you create in your home directory. (The “AUTHORIZED_KEYS FILE FORMAT” section of the sshd man page explains more.)
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.)
By the way, if you’re looking for a similar solution for the git version control system, you can use something similar in your “authorized_keys” file:
command="/usr/bin/git-shell -c \"$SSH_ORIGINAL_COMMAND\"" ssh-dss A0B1C2D3...
There are several pages on the Internet explaining more about this (search for git-shell ssh authorized_keys), including this one on superuser.com.
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.