situation normal all fucked up

I finally split up my big ugly SVN repository into dedicated repos for each project. The process to do this is a little tricky, so I thought I’d write it up here:

1. make a dump of the whole repository with svnadmin dump REPOSITORY > svn.dump
2. create a new repository for each project with svnadmin create PROJECT
3. for each project, run svndumpfilter include PROJECT --drop-empty-revs --renumber-revs < svn.dump | svnadmin load REPOSITORY
   • PROJECT is the project path in the original repository (e.g. trunk/foo)
   • REPOSITORY is the path to the new repository you just created
   • if you made copies inside the repository which were originally outside the project path, you’ll have to include those too
   • you also may want to rewrite the toplevel folder, for example if you had trunk/foo in the old repository and want to have those files directly inside trunk in the new one, use sed -r "s|^(Node-.*path): trunk/foo|\1: trunk|" before the svnadmin call
4. if all goes well, you now should have a new repository with only the desired files in it
5. you need to checkout new working copies, svn switch doesn’t work here because you’ve created a completely new repository

If you use Apache with authz authentication, there will be some problems when you try to serve multiple repositories. The following configuration works for me (inside <VirtualHost>):

RewriteEngine On
RewriteRule ^(/svn)$ $1/ [R]
<Location /svn/>
   DAV svn

   SVNParentPath /var/lib/svn
   SVNListParentPath On
   SVNIndexXSLT /stylesheets/svnindex.xsl

   AuthType Digest
   AuthDigestDomain /svn/
   AuthName "svn"
   AuthUserFile /etc/apache2/passwd

   AuthzSVNAccessFile /var/lib/svn/access
   Satisfy Any
   Require valid-user
</Location>

• you have to add a slash at the end of the <Location> tag
• the RewriteRule is necessary to make /svn (without the slash) still work
• inside the authz configuration file, you can reference repositories with the [repo:path] syntax, see the SVN Book for more information

There are a lot of howtos for this on the net, but most of them are far too in-depth, and left me just more confused. So here’s my version:

1. Install the openssl package.
2. Run the following command to generate a self-signed certificate which will expire in about 10 years:
   

   openssl req -new -x509 -days 3650 -nodes \
    -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem

3. Fill in the fields as you like, just make sure the server name (“Common Name”) matches your actual domain.
4. The certificate will be saved in /etc/apache2/ssl/apache.pem. You can rename it if you want, and also delete the symlink. Just make sure the file is only readable by root.
5. Enable the SSL module with a2enmod ssl.
6. Add the line Listen 443 to /etc/apache2/ports.conf if it isn’t already there.
7. Now here’s where I got stuck at first. There are two things you have to keep in mind:
   • You can only have one SSL-enabled virtual host per IP address. This is a limitation of SSL itself.
   • You need to have a separate vhost for the SSL-enabled site.
8. If you’re like me, you just want everything to be also available through SSL, but don’t want to maintain two separate configurations. Fortunately you can move all settings into a separate file and Include them inside the virtual host:
   1. Create a new file in /etc/apache2/sites-available with all your current settings (without the enclosing <VirtualHost> tag).
   2. Replace your default site configuration with something like this (make sure to change the Include lines and the path to your certificate):
      

      NameVirtualHost *:80
      <VirtualHost *:80>
          Include /etc/apache2/sites-available/snafu-base
      </VirtualHost>
       
      NameVirtualHost *:443
      <VirtualHost *:443>
          SSLEngine On
          SSLCertificateFile /etc/apache2/ssl/snafu.selfip.org.pem
          Include /etc/apache2/sites-available/snafu-base
      </VirtualHost>

9. Restart Apache with invoke-rc.d apache2 restart.

Now you should be able to access your site over HTTPS. Your browser will probably display a warning because the certificate is self-signed.