Development Applications
SVN
Subversion is the successor to CVS with several improvements. There is considerable progress towards versioning of directories and improved meta information (setting properties on objects). From a usability perspective Subversion repositories can be manipulated through WebDAV portals, ie. a repository can be http://svn.example.com/repos.
One aspect of Subversion that confuses users but becomes second nature with use is that no individual entity in a repository has a version number, rather, every commit is reflected in a change to the version of the repository as a whole.
Note
From at least Solaris Nevada b63 Sun are distributing a suitable copy of Subversion in /usr/bin including the required WebDAV modules in /usr/apache2. Good news. Unless you want to use Trac as Sun aren't distributing SWIG and thus can't be building the Subversion/Python bindings for us. So we have to do the legwork anyway.
Build and Install
Building Subversion is surprisingly tricky partly because it requires several subcomponents to deliver the WebDAV functionality and because it's hard to convince the build process to use the version you want it to. A particular beef is with Apache's APR modules and the expat XML parser which the build scripts will find (probably accidentally) in /usr/local/lib.
Warning
At the time of writing, neon, required for the Subversion client-side code, only worked with version 0.9.x of APR. Solaris 11 build 59 and later distribute Apache 2.2 which uses a later version of APR (1.2.x). You'll get all sorts of difficult to diagnose programs because the libraries don't match. A workaround is to build an instance of Apache 2.0 which, if push comes to shove, can run on a protected port (eg. on localhost only or fronted by a firewall) and use ProxyPass on the real server.
Neon Library
Neon is used for the Subversion client-side code to access WebDAV repositories. The Neon library is included in the subversion-deps bundle but so is Apache's APR modules as well as zlib. The subversion-deps APR is likely to conflict with the webb server's APR libraries with distressing results. It's easier if we just build Neon independently.
Oh, and Subversion only builds against neon version 0.25.5...
In keeping with Solaris' peculiarities, Neon gets in a real tizzy unless we specify --with-pic.
cd .../neon-0.25.5
./configure --prefix=/usr/local/${PWD##*/} --with-pic --with-ssl=openssl
make
make install
Note
If you are studious enough to run a make check then on every Solaris 11 variant I've tried it fails a single date parse test. YMMV.
Subversion Build
The Subversion build is straight-forward noting that we need to point to the apxs of our web server, the apr-config and apu-config programs as well as to the top of our version of Neon.
cd .../subversion-1.4.3
./configure --prefix=/usr/local/${PWD##*/} \
--with-apxs=/usr/local/httpd-2.0.59/bin/apxs \
--with-apr=/usr/local/httpd-2.0.59/bin/apr-config \
--with-apr-util=/usr/local/httpd-2.0.59/bin/apu-config \
--with-neon=/usr/local/neon-0.25.5 \
--with-swig=/usr/local/swig-1.3.31
make
make install
make swig-py
make install-swig-py
You may not want to run make check as it takes some hours to complete.
Configuration
Subversion works out of the box (as you might expect!). Read the excellent Red Book for how to manage Subversion.
Our troubles begin when we want to have multiple users access the repository -- normal Unix users and groups stuff. In our setup, we want to manipulate the repository through WebDAV so we need to grant the web server access to the repository. With a suitably configured webserver you may decide that ordinary users need not access the repository through the file system at all but always access it through WebDAV.
Of course, the security conscious will recognise the risk of having a web server being subverted (ho ho) and messing with your repository but if that was your fear you wouldn't be accessing your repository through WebDAV URLs!
File system permissions aside read the excellent commentary on securing your WebDAV system in the Apache HTTP Server section of the Red Book.
If you've set the Apache 2.0 server up for Subversion yet are still using Sun's apache2 installation for everything else then note that you only need use ProxyPass in the main server to redirect to the Subversion Apache server running on localhost. The resultant configuration can be stripped down to:
<VirtualHost ...>
# some logging, maybe
ProxyPass / http://localhost:{PORT}/
ProxyPassReverse / http://localhost:{PORT}/
</VirtualHost>
Subversion Issues
WebDAV
Subversion doesn't cope very well with exuberant redirect or any other status messages from the web server. In Apache-speak you'll want to:
ErrorDocument 404 default
within the Subversion virtual host. See Redirects below.
SSL
The first time you use Subversion through WebDAV you will experience some bootstrap issues. If you're accessing via SSL (or redirecting to a SSL service) you'll be prompted to verify the certificate. That seems fine. However, it doesn't then successfully pick up on a HTTP Authentication mechanism properly. You'll have to issue your svn command again.
Redirects
Despite having listed it above I didn't really understand the issue the first time around. You cannot use redirects with svn. In a situation where access to the repository is granted through an SSL service (which may happily use ProxyPass under the hood) you may want to allow vanilla http: URLs to be redirected to the SSL service. Sadly this, and any other redirect mechanism if you have shifted the location of your SSL service, will simply fail with an obscure message:
svn: PROPFIND request failed on '...' svn: PROPFIND of '...': 302 Found (http://svn.example.com)
svn does not understand redirects.
Just use the https: URL and be done.
If you've moved your repository (ie. changed your web service around) ask your users to svn switch their repositories.
Document Actions