Subversion considerations and caveats

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.

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 https://svn1.example.com/repo, you cannot have a second repository named https://svn2.example.com/repo. If you do configure https://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.

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.

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).

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.

You'll need to install the PECL extension SVN:

• PECL svn extension download

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

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.