Hastily-made repositories often don't work
If you create your repository before its URL has been created and is resolving online, you may have an inaccessible repository. Assuming it doesn't yet contain any information, just delete it and recreate it.
Alternatively, you may experience a DNS propagation delay if you can access your repository via http within the DreamHost system, but see an empty directory from outside DreamHost. If you can't wait, try querying the DreamHost DNS servers for your IP and use a local hosts file or NetInfo to temporarily resolve your svn host. Remember to undo this when DNS records have propagated.
Hosting more than one Subversion domain
You can host multiple svn domains and subdomains under one DreamHost account, but they are not completely independent. In particular, all repositories created with the same FTP user share the same namespace, even if under different URLs. With a single FTP user, a given repository name can only be used once for all svn domains.
If you create http://svn1.example.com/repo, you cannot have a second repository named http://svn2.example.com/repo. If you do configure http://svn2.example.com/repo, it is a second name for the same repository, with a separate set of permissions. If you must create two repositories with the same name, create a second FTP user.
Hosting Subversion for a domain that is not on DreamHost
If you have a domain which is not hosted on DreamHost and you want to set up Subversion on a subdomain of that domain, it will not work with a normal setup.
You must configure a subdomain such as realsvn.exampleOnDreamHost.com, then create a subdomain for svn.exampleNOTonDreamHost.com.
Finally, create a mirror to that domain from the domain you want. Make sure you wait for DNS propagation to occur before testing everything.
Handmade repos are read-only
If you find that you have to tweak and reload your dumpfile a few times, it can be handy to use the CLI tools (e.g., rm -rf and svnadmin create) to wipe and recreate your repository until you get it right. But then you'll want to use the panel to delete and recreate your repository. Your test repositories will not function properly in production as they won't permit any changes.
The panel creates the repository with dhapache as the owner, and the reponame.access and reponame.passwd files with dhapache as the group. Trying to create your own production repo with svnadmin create is futile because you don't have authorization to change those ownerships and group memberships (and you're not a sudoer).
Don't overwrite dhapache files. Overwriting files causes them to have your user's group instead of dhapache. If your repository is relatively mature when you make this mistake, and you have no backup, you won't have any options.
Some clients require MD5 passwords
If you get "access denied" warnings, you may need to use MD5 passwords instead of the standard variety created by the DreamHost panel. Use htpasswd -nm username to generate the entry (ala username:passwd-hash) for your reponame.passwd file, then use an editor to replace your standard password entry.
Don't overwrite your reponame.access> and reponame.passwd files with echo "username:passwd-hash" > reponame.passwd. Overwriting files causes them to have your user's group instead of dhapache, leaving your repository in a read-only or inaccessible state.
Interfacing with Subversion from PHP
You'll need to install the PECL extension SVN:
Subversion can be a very useful tool for developing web sites or web-based applications. You may wonder, though, how that would work. After you commit your changes to your repository, how do you have them reflected on your site? The easiest method is to have your site's directory on the server set as a working copy checked out from your Subversion repository. If you elect to do this, be certain to modify your site's .htaccess to prevent users from browsing Subversion's control files. Something simple in the root of your site such as the following should suffice:
RedirectMatch 403 /\.svn
Using Apache basic authentication
The prior section's steps require each user to have a Unix account with shell access so they can log in via SSH. However, the DreamHost panel provides a way to create user accounts only for Subversion.
But for those accounts, if you want to specify who has read vs. read-write access and/or per-directory of your repository, you must manually edit the .access file as described in the latest Subversion manual on "Per-directory access control" and DreamHost's implementation of this feature. You can manually add and administer the usernames and passwords for Subversion by using htpasswd to add/edit users to the .passwd file for your repository.
Note after manually editing either the .access or .passwd files
- The file's group changes from dhapache to whatever the auto-generated group for your account is, which prevents the Apache module from being able to read the files, so you then need to change the permissions so that they can be read by Apache(do "chmod 644").
- You will also need to be prepared that if you now use the DreamHost control panel to change settings (at least if you make changes to the user list), the panel not only reverts the file permissions back to dhapache but also overwrites both files, overwriting any changes you made to them. So you'd should always have a backup to reconstruct anything important that might get overwritten.
"chmod 644" is giving "world" read access to those files which may be a security risk. While these files won't be accessible via http (unless you also publish your svn/ which would likely be unwise), these files are accessible to other shell users to your account and MAYBE by other DreamHost account holders on your shared host. Therefore, for real security, you should not use http, but instead https (which is also the only option if accessing via WebDAV) or SSH.