Building an OS X based Subversion Server

Overview

This article explains in-depth how to build a Subversion server on OS X.  While building a Subversion server is the purpose of this article, a lot of the information you learn is operating system agnostic. So, whether you're building a Linux-based Subversion server or a Windows-based Subversion server, a lot of the same rules and procedures will apply. That being said, let's get started.

Installation

The first order of business is to install Subversion.  As of OS X 10.5 (Leopard), Subversion is shipped with the core operating system.  Whether you are looking to upgrade the 1.4.4 version installed with Leopard or you need to install for Tiger, there is a full-featured Subversion binary for  OS X offered on openCollabNet.  We just released the Subversion 1.6.2 binary last week.  If you're new to the binary, let me tell you a few of its most important features:
  • The binary provides a complete Subversion installation
  • The Subversion installation is a 4-way universal binary (i386, ppc, x86_64 and ppc64) 
  • Works on any version of OS X, 10.4.x+
  • Includes the Apache modules and svnserve built with SASL support
  • Includes both repository data stores (Berkeley DB and FSFS) 
  • Includes the Subversion language bindings maintained by the Subversion team (Java, Perl, Python and Ruby)
  • Packaged in an easy-to-use graphical installer package
  • Completely isolated and does not interfere with any other installed Subversion binary 

As you can see, this binary is quite complete and being packaged in an installer makes the installation simple.  How simple?  Just download, open the .dmg file, double-click the .pkg and follow the instructions.  The only thing left is to make the newly-installed Subversion the default Subversion by updating your PATH environment variable.  This can be done a multitude of ways and differs based on the terminal you use but if you're using the default, you can append the following to your /etc/profile file:

export PATH=/opt/subversion/bin:$PATH

Once you've done this, you should be able to launch Terminal.app, run "svn –version" and see the information from your new Subversion installation.  Now that we've got Subversion installed, let's go ahead and create a few Subversion repositories so we can serve them from our new Apache-based Subversion server.

Creating repositories

Since we plan on serving multiple Subversion repositories, let's create a container directory for those repositories.  To do this, run the following:

sudo mkdir -p /opt/repos/svn

Once you have the container directory created, you can then create your repositories using the "svnadmin create" Subversion command like so:

sudo svnadmin create /opt/repos/svn/test

Change the path and repository as needed and then repeat the process until you have all of your repositories ready.  If you already have repository you'd like to serve, just move them to your new repositories container.

Setting up the Server

Most of the time when people setup Subversion servers, the first problems they run into is related to file system permissions.  Whether you use Apache or svnserve, your file system permissions need to be so that the user that Apache or svnserve run under has the proper permissions to access the repository file system structure, since Subversion repositories are nothing more than a directory structure.  For this example, we'll be running Apache and we need to fix the permissions so that the default Apache user and group can read/write the file system.  To do that, run the following:

sudo chown -R www:www /opt/repos/svn

Now that we have the file system permissions fixed, we can setup Apache to serve our repositories.  Below is a very simple example of how you might do that.  If you want a more in-depth example, please review my earlier blog entry titled "Subversion with Apache and LDAP".

# Load Subversion Apache Modules
LoadModule dav_svn_module /opt/subversion/lib/svn-apache/mod_dav_svn.so

# Work around authz and SVNListParentPath issue
RedirectMatch ^(/repos/svn)$ $1/

# Enable Subversion logging
CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION

<Location /repos/svn/>
# Enable Subversion
DAV svn

# Directory containing all repository for this path
SVNParentPath /opt/repos/svn

# List repositories collection
SVNListParentPath On
</Location>

You can also use the excellent Apache documentation on authentication, authorization and access control.  The only remaining thing let to mention is something I ran into when building a Leopard-based Subversion server on a 64-bit system.  Basically Apache is built and ran as a 64-bit application in Leopard.  When you start up Apache after installing the binary linked to above, you might see an error about missing/undefined symbols.  The reason for this is that Apache on Leopard uses /usr/sbin/envvars when you start up Apache and it is built to set the DYLD_LIBRARY_PATH to pick up libraries from /usr/lib.  Well, since our version of Subversion installs to /opt/subversion, you end up with the Apache modules attempting to use old/missing libraries.  To fix this, just update /usr/sbin/envvars to prepend /opt/subversion/lib to the DYLD_LIBRARY_PATH and you'll be good to go.  (Note: I've been told that this step causes another issue where Apache tries to use the APR shipped with the OS X binary.  To avoid this, make sure both lines, the definition of DYLD_LIBRARY_PATH and the export line, are commented out.)

To test, open Terminal.app and run the following:

sudo apachectl -k start

You can then open your browser to http://localhost/repos/svn and you should see a listing of your repositories.

Summary

As you can see, installing Subversion and configuring it for OS X is very simple.  While there are a few things that you need to know to guarantee a smooth installation, for example filesystem permissions and the Apache modules issue, everything else is relatively simple.  I hope this article helps those of you building OS X based Subversion servers.

(Updated on 06/04/2009 to fix a typo and to add a note about /usr/sbin/envvars.)

Tagged with: , ,
Posted in Subversion
69 comments on “Building an OS X based Subversion Server
  1. If running SubVersion behind Apache HTTPD is a bit too much for your purposes, you could configure svnserve into launchd on the mac. That way your repositories are hosted by svnserve on demand.
    Read more about how to do that on this URL:
    http://marc.baffl.co.uk/stuff.php#svnserv-plist

  2. Niels Hansen says:

    Thanks for the article. I installed the dmg and made the changes to my httpd.conf file however I am getting the following error when I start apache.
    httpd: Syntax error on line 116 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Library not loaded: /opt/subversion/lib/libaprutil-1.0.dylibn Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.son Reason: Incompatible library version: mod_dav_svn.so requires version 4.0.0 or later, but libaprutil-1.0.dylib provides version 3.0.0
    I don’t know if I need to use
    LoadModule dav_svn_module /opt/subversion/lib/svn-apache/mod_dav_svn.dylib
    because that did not work so I changed the ext to .so (there was no dylib file in that folder)
    I also tried updating /usr/sbin/envvars but I also received other errors. Any clue based on this error why this would not work?
    I have updated to 10.5.7 the other day so I’m not sure if that has anything to do with it.
    Thanks!

  3. Niels,
    You are right. You should be using “.so” extensions for the Apache Subversion modules. I’m not sure if you followed the instructions or not but if you updated the /usr/sbin/envvars to either remove the DYLD_LIBRARY_PATH environment variable or you set it to have /opt/subversion/lib in the front, that should work. I have Apache serving Subversion with the same Subversion client and Apache modules shipped in the binary so there has to be some sort of disconnect between what I have configured and what you have configured.

  4. BL says:

    I believe I’ve followed your instructions to the letter on 2 Macs and am getting the same error with each:
    dyld: Symbol not found: _apr_socket_sendfile
    Referenced from: /usr/sbin/httpd
    Expected in: /opt/subversion/lib/libapr-1.0.dylib
    I’ve updated the envvars to read:
    DYLD_LIBRARY_PATH=”/opt/subversion/lib:/usr/lib:$DYLD_LIBRARY_PATH”
    Any advice would be appreciated.

  5. Jasen says:

    Why is the new install path /opt? OS X does not have this path by default. Using that path creates a new root level directory just for subversion. Is there a reason /usr/local was not acceptable?

  6. BL,
    Can you provide more information about your system:
    OS X version
    Apache version
    I’ve not had this reported before.

  7. Jesen,
    The purpose of this was to create an installation location what would not conflict with any other Subversion installation. /opt is a standard location for optional software and so it seemed like a good place. I did install to /usr/local early on but it conflicted with some other Subversion installations like SCPlugin. Subversion developers also reported it was causing build anomalies. That’s when I decided to put it in an isolated place to help avoid conflicts.

  8. BL says:

    Jeremy,
    Thanks for getting back to me. I’m running the latest version of OS X: 10.5.7 with the default Apache install of 2.2.11 and I’ve tried this on both an iMac and a Mac Mini.

  9. BL,
    My last question is are you on a PPC-based Mac or an Intel-based Mac? I’m still not seeing anything like this reported before. I’ll keep digging while you respond.
    Take care,
    Jeremy

  10. BL says:

    They are both intel based. I’ve also got a intel macbook lying around so after a backup this weekend I’ll have a go at getting it setup on there.

  11. BL,
    I think I have figured this out. How are you loading the Subversion Apache modules? The mod_dav_svn you’re loading appears to be looking for an APR that has sendfile defined. I do not build apr with sendfile to work around a bug. It sounds like you’re loading the Subversion Apache modules shipped either with Leopard or with another binary that isn’t mine yet you’re telling Apache to use the libraries shipped with my binary. Can you tell me how you’re loading the Apache modules?

  12. Chad says:

    Hi Jeremy,
    I’m having the exact same problem as BL, and same system config. I first got the DYLIB error, now getting the _apr_socket_sendfile error.
    I followed the instructions above to the letter, but could this be an issue:
    httpd.conf
    ———-
    ..
    LoadModule dav_module libexec/apache2/mod_dav.so
    .. (then at the end the new block:)
    # Load Subversion Apache Modules
    LoadModule dav_svn_module /opt/subversion/lib/svn-apache/mod_dav_svn.dylib
    # Work around authz and SVNListParentPath issue
    RedirectMatch ^(/svn/imi_repos)$ $1/
    # Enable Subversion logging
    CustomLog logs/svn_logfile “%t %u %{SVN-ACTION}e” env=SVN-ACTION
    # Enable Subversion
    DAV svn
    # Directory containing all repository for this path
    SVNParentPath /Users/chada/Desktop/Archive/Projects/IMI-Web
    # List repositories collection
    SVNListParentPath On

  13. Chad says:

    Sorry, that wasn’t too clear, I meant following up on your conjecture that a native apache library was looking for the missing symbol in your modules, I noticed that the regular dav_module was being loaded from the regular filesystem and then dav_svn_module is being loaded from your custom code.
    Just a stab. I’m a newbie πŸ˜‰

  14. Well, it should be “/opt/subversion/lib/svn-apache/mod_dav_svn.so” instead of “/opt/subversion/lib/svn-apache/mod_dav_svn.dylib”. I’m not sure if that is what you meant from “DYLIB error” or not. As for mod_dav being loaded the way it is, that’s no problem. I just wanted to make sure BL and yourself were loading the Subversion Apache modules from /opt/subversion/lib/svn-apache.
    The more I look around, to try and figure out why my environment works and yours doesn’t, I realize that my /usr/sbin/envvars and I see that I don’t have DYLD_LIBRARY_PATH defined. I have that line commented out. Maybe you can try that. I’m at a loss. That’s the only thing I can see that is different between what I’ve put into my blog entry and what I have locally (working).

  15. Aaron says:

    Jeremy: Commenting out DYLD_LIBRARY_PATH from my /usr/sbin/envvars (and /usr/sbin/envvars-std to be safe) solved the “dyld: Symbol not found: _apr_socket_sendfile” problem on my system. We’ll see if it causes other problems, but for now, at least dav_svn seems to be working.
    Thanks for the info!

  16. Chad says:

    Yes, Jeremy, this is a great article! Something this comprehensive was hard to come by.
    I changed .dylib to .so in httpd.conf, commented out DYLD_LIBRARY_PATH from /usr/sbin/envvars, and apache starts up fine.
    The next 2 problems I had were solved by 1.) creating the file /usr/logs/svn_logfile which was of course absent, and starting up Web Sharing in the System Preferences.
    Now, I’m back to a permissions problem, as when I try to access http://localhost/svn/imi_repos/trunk/, I get ” Could not open the requested svn filesystem”, although http://localhost/svn/imi_repos shows the regular small list of svn top level links (“branches”,”trunk”, etc).
    I did run the command: sudo chown -R www:www /Users/chada/Desktop/Archive/Projects/IMI-Web
    and it chown’s to _www instead of www. Is this normal or is this a symptom of something else?

  17. I don’t know why /usr/logs was required to be created. It should log to the same place Apache logs the access and errors to. Regardless, glad to hear you got it working. As for permissions, yes, _www is expected.

  18. I have updated the article to fix the name of mod_dav_svn and also to add a note about updating /usr/sbin/envvars.

  19. Ben Feist says:

    Hi Jeremy, Very good post. I’m having the same trouble with the envvars paths and getting an error looking for sendfile. Here are the scenarios:
    with DYLD_LIBRARY_PATH completely commented out (with the export statement) which in my case leaves a completely empty envvars file. I get the following error when i try to start apache with apachectl -k start:
    httpd: Syntax error on line 118 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Symbol not found: _dav_push_errorn Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.son Expected in: flat namespacen
    with DYLD_LIBRARY_PATH defined as:
    DYLD_LIBRARY_PATH=”/opt/subversion/lib”
    export DYLD_LIBRARY_PATH
    I get the following error when i try to start apache with apachectl -k start:
    dyld: Symbol not found: _apr_socket_sendfile
    Referenced from: /usr/sbin/httpd
    Expected in: /opt/subversion/lib/libapr-1.0.dylib

  20. Ben,
    Can you tell me a little more about your environment? OS version, CPU architecture and Subversion version are most important. We’ll go from there.
    Take care,
    Jeremy

  21. Ben Feist says:

    thanks for the help.
    OSX 10.5.6
    Dual PowerPC G5 CPUs
    SVN version: 1.6.2 (r37639) compiled May 14 2009
    (from the collabnet package)

  22. Kieren Eaton says:

    Hi Ben
    ok the problem you are experiencing seems to be related to the OS X factory version of Apache.
    it looks for the sendfile symbol in the libapr-1.0.dylib. The subversion version (universal installer) of this file does not seem to have this symbol in it. It may be possible to compile the subversion libs to include this but I have not yet needed to investigate that possibility.
    The standard version 1.0.2.7 of this in /usr/lib has the sendfile symbol and so the webserver works out of the box.
    that is why uncommenting the path makes it work again.
    i would suggest that you relink the /opt/subversion/lib/libapr-1.0 back to the original in the /usr/lib folder
    possibly the libaprutil could be involved too?
    then you can uncomment the added DYLD_LIBRARY_PATH in your config for the subversion lib folder
    I dont use the apache server at all for my subversion work but managed to get my break my web sharing with the same problem.
    HTH

  23. Ben Feist says:

    relinking is a bit beyond my experience. Would reinstalling apache from another binary package work?

  24. Well, I can rebuild the binary with the apr symbol but that doesn’t really fix what’s going on here. If you have any request to resolve the ‘_apr_socket_sendfile’, you’re loading the wrong version of APR at runtime. Relinking shouldn’t help. While I was thinking it could be how I’m building the 4-way universal binary, the error you are getting means there is a problem is do to your mod_dav_svn.so loading apr delivered with Leopard instead of the one I link against and ship with my binary. Something is mucking with your loader path. Aaron above was successful in getting this binary working by just uncommenting the two lines in the /usr/sbin/envvars file.
    I’ll look into another way to handle this when 1.6.3 comes out if possible.

  25. Florin Rosca says:

    Hi Jeremy,
    I am trying to set up my svn server to work over ssh. It looks like there is no way to do that short of recompiling sshd
    The reason:
    sshd comes with a precompiled PATH (/usr/bin:/bin:/usr/sbin:/sbin)
    Adding export PATH=/opt/subversion/bin:$PATH to bashrc does not work for ssh remote commands (ssh doesn’t seem to create a shell when executing remote commands):
    ssh [username]@[host] svn –version
    svn, version 1.4.4
    ssh [username]@[host]
    # svn –version
    svn, version 1.6.2
    As a result, I get this when I try to check out:
    Expected FS format β€˜2β€² ; found format β€˜4β€²
    Any ideas?
    Thank you,
    Florin

  26. Stefan Keller says:

    I did everything as described, but still get
    “cannot load … mod_dav_svn.so into server: (reason unknown)”.
    from within the Server-Admin-Application.
    I did this on my XServe runnig
    Mac OS X Server, Version 10.5.7. 2x2GHz Dual-Core Intel Xeon, 2GB RAM
    SVN version: 1.6.2 (r37639) compiled May 14 2009
    (from the collabnet package)

  27. Florin,
    That means that you have created a repository with a newer Subversion library but are trying to use it locally with an older library, which isn’t possible. Update your PATH so that you use the newest Subversion binary and this should not be an issue.
    Stefan,
    “(reason unknown)” is something I’ve not run into before. Can you try starting up Apache from the command line to see if you can get a useful error? Maybe even look in the Apache error logs. Let me know and we’ll continue.
    Take care,
    Jeremy

  28. Florin Rosca says:

    Hi Jeremy,
    I am trying to set up a svn server and access it remotely over ssh.
    I was trying to point out that:
    1. OS X comes with an older version of svn in /usr/bin
    2. Your package installs the newer svn in /opt/subversion/bin
    3. The library that connects to the server (in my case, Eclpse SvnKit) issues remote commands to server over ssh.
    4. The remote commands are always executed on the server by the older svn binary because sshd has a built-in path (/usr/bin:/bin:/usr/sbin:/sbin).
    This means that trying to access a new repository over ssh (svn+ssh://user@host/path) does not work even if I update the PATH.
    For now I will stick with the old version.
    Thanks,
    Florin

  29. Libby says:

    I’m having the same problem Florin had. I am running 1.6.3 on both my server (PPC XServe) and my client (Intel MacBook Pro). When I try svn+ssh, I get “Expected FS format β€˜2β€² ; found format β€˜4β€²” even though “svn –version” locally and remotely returns 1.6.3. Any ideas? Thank you!

  30. Well guys, this is an environment issue. The binary works fine and your problem has nothing to do with the CPU architecture. The reason for the problem is that when accessing via SSH, your PATH environment variable doesn’t have /opt/subversion/bin in front of /usr/bin, so that you use the newer binary instead of the one shipped with Leopard. This is an SSH configuration issue that can be solved a few different ways. One would be to update the /etc/sshd_config to enable the AcceptEnv option and then you can configure your client using /etc/ssh_config. This is common practice and has nothing to do with Subversion.
    Good luck.

  31. Russell Geraghty says:

    I’m having the same problem as Stephan above. This is the output of sudo apachectl start:
    mini:/opt russell$ sudo apachectl start
    Processing config directory: /private/etc/httpd/users/*.conf
    Processing config file: /private/etc/httpd/users/russell.conf
    Processing config directory: /etc/httpd/conf.d/*.conf
    Processing config file: /etc/httpd/conf.d/svn.conf
    Syntax error on line 2 of /etc/httpd/conf.d/svn.conf:
    Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: (reason unknown)
    /usr/sbin/apachectl start: httpd could not be started
    There is no output in /var/log/httpd/error_log
    The host operating system is OS X 10.4.11 Build 8S165 running on a Mac Mini PowerPC G4
    I get the same error when trying to install Subversion 1.5.6, 1.6.1 and 1.6.3
    Any ideas? Thanks.

  32. I’m currently working on getting access to a PPC-based Mac. I won’t be able to do this alone until then. In the mean time, can you try to start Apache without apachectl to see if you get any extra information? Just “sudo httpd”. What happens?

  33. Russell Geraghty says:

    Hi Jeremy,
    This is the output for sudo httpd
    mini:~ russell$ sudo httpd
    Password:
    Processing config directory: /private/etc/httpd/users/*.conf
    Processing config file: /private/etc/httpd/users/russell.conf
    Processing config directory: /etc/httpd/conf.d/*.conf
    Processing config file: /etc/httpd/conf.d/svn.conf
    Syntax error on line 2 of /etc/httpd/conf.d/svn.conf:
    Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: (reason unknown)
    No output in /var/log/httpd

  34. Just for grins, can you both run “httpd -v” to get the Apache version? If it’s not Apache 2.2.x, that would explain this.

  35. Philip Woeber says:

    I have a new Mac Pro with OS X 10.5.7,
    Apache/2.2.11 (Unix), and
    svn, version 1.6.2 (r37639).
    I followed your instructions exactly
    and studied your dialogs with Florin et al.
    I put your LoadModule and RedirectMatch stuff in http-subversion.conf and
    added “Include /private/etc/apache2/extra/httpd-subversion.conf” to httpd.conf.
    I commented out the two DYLD_LIBRARY_PATH lines in envvars-std.
    With envvars configured as follows:
    DYLD_LIBRARY_PATH=”/opt/subversion/lib:/usr/lib:$DYLD_LIBRARY_PATH”
    export DYLD_LIBRARY_PATH
    I got the same error others got after “sudo apachectl -k start”
    dyld: Symbol not found: _apr_socket_sendfile
    Referenced from: /usr/sbin/httpd
    Expected in: /opt/subversion/lib/libapr-1.0.dylib
    When I comment out the two DYLD_LIBRARY_PATH lines in envvars,
    I get no response at all after running “sudo apachectl -k start”.
    I keep a separate Terminal shell running with top and httpd doesn’t even pop up.
    I don’t know what else to try. By the way, I downloaded a great Show Hidden Files.app from http://automatorworld.com/archives/show-hidden-files/

  36. Well, if you commented out the two lines in /etc/envvars and you get no output when you start Apache, that’s good. When you start Apache with “sudo httpd” or “sudo apachectl”, you should have nothing returned to you but your terminal if things go as expected. To verify this, after starting Apache, “sudo ps aux | grep ‘httpd'” to see the httpd processes or you can browse to the localhost to see that Apache is indeed working. Can you try this and let me know?

  37. Russell Geraghty says:

    Hi Jeremy,
    That’d be it then, Tiger ships with 1.3:
    mini:~ russell$ httpd -v
    Server version: Apache/1.3.41 (Darwin)
    Server built: Feb 22 2008 09:40:00

  38. Well, for me that is great news. πŸ˜‰

  39. Russell Geraghty says:

    I should learn to read the pre-requisite list before installing πŸ˜‰

  40. Philip Woeber says:

    I went back to svn 1.4.4
    I will try svn 1.6.2 another time.
    Thanks

  41. Philip,
    Can you see if any of the comment above shed light on the subject? It appears some people with the same issue with you were due to either the wrong version of Apache or not following the document completely so that all lines in envvars were commented out. 1.4.x is such an old version that I’d hate to see you go back because of this. If you can tell me anything more, I’d love to help:
    CPU Type
    OS Version
    Apache Version
    Exact Error
    Yes…I know you’ve posted some of this in the past but I’d like one location for all of this.

  42. Loren Cahlander says:

    Have you setup svnserver in Mac OS X Server Snow Leopard?
    I am trying to setup access for different repositories to be based off of the group from Open Directory.

  43. John says:

    I actually had to point the dav_svn to my apache version on snow leopard to get rid of my seg faults.
    Here is the change I had to make to get everything working.
    # Load Subversion Apache Modules
    # LoadModule dav_svn_module /opt/subversion/lib/svn-apache/mod_dav_svn.so
    LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so
    I don’t know why the collab module was having a problem, could just be that snow leopard is still so new.

  44. John,
    Yes…I’m currently tracking down a problem with my binary on Snow Leopard. The good news is the problem only appears to happen with Apache. Sorry for the inconvenience.
    Take care,
    Jeremy

  45. Samuel Smith says:

    I tried installing Subversion 1.6.6 (tried 1.6.5 before same resuts) on Dual 1.8 Ghz G5 power mac with Leopard Server 10.5.8 v1.1.
    I believe I followed the directions:
    but I still get the the error
    $ apachectl -t
    dyld: Symbol not found: _apr_socket_sendfile
    Referenced from: /usr/sbin/httpd
    Expected in: /usr/lib/libapr-1.0.dylib
    /usr/sbin/apachectl: line 81: 3445 Trace/BPT trap $HTTPD $ARGV
    I did comment out lines in /usr/sbin/envvars and envvars-std
    The difference in my installation is that I want to be able to use xcode and for that (as per other comments on other websites)
    I have to change the symlinks in /usr/lib
    and also copy the apache modules to /usr/libexec/apache2.
    Any idea why its not working.
    I tried this several times and to make it easy to go back and forth I wrote a couple of shell scripts to automate the process.
    So you can see exactly what I did.
    —————————–
    #!/bin/bash –
    # svnsymlink.sh
    # Sam Smith 20091022
    BACKUPLIB=”/backup/subversion/usr/lib”
    echo “”
    echo “Backing up subversion installation to $BACKUPLIB”
    sudo mkdir -pv “$BACKUPLIB”
    #cp -Rpv #-R copies symbolic links without following them, p preserves permissions
    sudo cp -Rpv /usr/lib/libap*-1.dylib “$BACKUPLIB” #copies symlink or file if not symlink
    sudo cp -Rpv /usr/lib/libap*-1.0.dylib “$BACKUPLIB”
    sudo cp -Rpv /usr/lib/libsvn*-1.dylib “$BACKUPLIB”
    sudo cp -Rpv /usr/lib/libsvn*-1.0.dylib “$BACKUPLIB”
    echo “”
    echo “Removing old symlinks”
    sudo rm -v /usr/lib/libap*-1.dylib
    sudo rm -v /usr/lib/libap*-1.0.dylib
    sudo rm -v /usr/lib/libsvn*-1.dylib
    sudo rm -v /usr/lib/libsvn*-1.0.dylib
    echo “”
    echo “Installing new symlinks”
    sudo ln -sv /opt/subversion/lib/*-1.0.dylib /usr/lib/
    sudo ln -sv /opt/subversion/lib/*-1.dylib /usr/lib/
    #fix up ra-dav symlink to point to ra-neon
    echo “”
    echo “Fixing ra_dav to point to ra_neon symlinks”
    sudo ln -sv /usr/lib/libsvn_ra_neon-1.dylib /usr/lib/libsvn_ra_dav-1.dylib
    sudo ln -sv /usr/lib/libsvn_ra_neon-1.0.dylib /usr/lib/libsvn_ra_dav-1.0.dylib
    BACKUPAPACHE=”/backup/subversion/usr/libexec/apache2″
    echo “”
    echo “Backing up subversion apache modules $BACKUPAPACHE”
    sudo mkdir -pv “$BACKUPAPACHE”
    sudo cp -Rpv /usr/libexec/apache2/mod_dav_svn.so “$BACKUPAPACHE” #copies symlink or file if not symlink
    sudo cp -Rpv /usr/libexec/apache2/mod_authz_svn.so “$BACKUPAPACHE”
    echo “”
    echo “Removing old modules”
    sudo rm -v /usr/libexec/apache2/mod_dav_svn.so
    sudo rm -v /usr/libexec/apache2/mod_authz_svn.so
    echo “Installing new modules”
    sudo cp -Rpv /opt/subversion/lib/svn-apache/mod_dav_svn.so /usr/libexec/apache2/mod_dav_svn.so
    sudo cp -Rpv /opt/subversion/lib/svn-apache/mod_authz_svn.so /usr/libexec/apache2/mod_authz_svn.so
    echo “”
    echo “Now fix /usr/sbin/envvars and envvars-std and restart apache”
    echo “”
    echo “Completed installation!”
    exit
    ———————–
    #!/bin/bash –
    # unsymlink.sh
    # Sam Smith 20091022
    BACKUPLIB=”/backup/subversion/usr/lib”
    echo “”
    echo “Restoring subversion installation from $BACKUPLIB”
    echo “”
    echo “Removing new symlinks”
    sudo rm -v /usr/lib/libap*-1.dylib
    sudo rm -v /usr/lib/libap*-1.0.dylib
    sudo rm -v /usr/lib/libsvn*-1.dylib
    sudo rm -v /usr/lib/libsvn*-1.0.dylib
    echo “”
    echo “Restoring old symlinks”
    sudo cp -Rpv $BACKUPLIB/*.dylib /usr/lib
    BACKUPAPACHE=”/backup/subversion/usr/libexec/apache2″
    echo “”
    echo “Restoring old subversion apache modules from $BACKUPAPACHE”
    echo “”
    echo “Removing new modules”
    sudo rm -v /usr/libexec/apache2/mod_dav_svn.so
    sudo rm -v /usr/libexec/apache2/mod_authz_svn.so
    echo “Restoring old modules”
    sudo cp -Rpv $BACKUPAPACHE/mod_dav_svn.so /usr/libexec/apache2/mod_dav_svn.so
    sudo cp -Rpv $BACKUPAPACHE/mod_authz_svn.so /usr/libexec/apache2/mod_authz_svn.so
    echo “”
    echo “Now fix /usr/sbin/envvars and envvars-std and restart apache”
    echo “”
    echo “Completed restoration!”
    exit

  46. Do you know if Apache worked before you mucked with the system-shipped libs? Also, installing the Subversion Apache modules I ship should not be referenced elsewhere so when your script tries to copy them to /usr/libexec/apache2/, I don’t think that’s a good idea either. As much mucking around as you’ve done, I’m not surprised that things aren’t working but I can’t place blame there either. Any way to get the system back to the way it was and try Apache that way?

  47. Samuel Smith says:

    SVN works fine with apache when I restore it back to 1.4.4.
    I know its preferable to not muck with the system installed versions. But xcode links directly to the dynamic libraries in /usr/lib so the only way to work with xcode is to replace. See.
    http://blindgenius.wordpress.com/2009/03/22/subversion-16-xcode-312-versions/
    http://stackoverflow.com/questions/1292190/installing-updated-svn-1-6-on-mac-os-x-to-integrate-with-xcode
    http://www.lemonteam.com/blog/2008/12/setting-up-subversion-15-on-xcode/
    Problem is the examples above are not os x server and using older versions of OS and SVN
    I have gone back and forth a few times. Could it be something different in OS X server? Maybe something is not getting unloaded in Apache, so apachectl -t is not using the new modules, just using module code from a cache?. I did restart the server at least once after making the changes just in case but still get the error.
    Maybe just changing the path in /etc/profile isn’t good enough but need to change it in /etc/path?
    Maybe I need to also replace the svn binaries in /usr/bin.

  48. Samuel Smith says:

    To be thorough I replaced the svn binaries in /usr/lib and flushed all the caches on the server and rebooted. Still get the dyld: Symbol not found: _apr_socket_sendfile error. This tells me that some other module besides your opt/subversion/lib/svn-apache/mod_dav_svn.so /opt/subversion/lib/svn-apache/mod_authz_svn.so is referencing the symbol. This maybe the difference between the OS X server and client versions.
    I restored to the originals and everything works fine.
    Is there some way to find out which module is referencing the symbol? Like changing the verbosity of the apache log or something?
    Would it be possible to rebuild the binary with _apr_socket_sendfile symbol defined?

  49. Samuel Smith says:

    I confirmed that it must be another module that is referencing _apr_socket_sendfile because I commented out the loading of the two svn modules with svn 1.66 installed and it still gave me the error

  50. Samuel Smith says:

    So I guess there is no response on this? I reverted back to 1.4.4. for now.

  51. Samuel,
    I’m sorry but you’ve mucked with your environment enough for it to be many things. The Subversion binary I maintain is known to work on Leopard without issue if you follow the instructions. I’m not sure what else to suggest other than to get Subversion 1.6.6 installed, as the installer installs it, and follow the directions above exactly. You’ve done many things that are not discussed above and at least one of them has altered your results.
    Take care,
    Jeremy

  52. Scott Hinckley says:

    Jeremy,
    How goes it with Snow Leopard?
    I tried it with no luck, My experience:
    envvars as shipped from Apple
    httpd: Syntax error on line 103 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Library not loaded: /opt/subversion/lib/libaprutil-1.0.dylibn Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.son Reason: Incompatible library version: mod_dav_svn.so requires version 4.0.0 or later, but libaprutil-1.0.dylib provides version 3.0.0
    envvars with added /opt/subversion/lib
    yld: Symbol not found: _apr_socket_sendfile
    Referenced from: /usr/sbin/httpd
    Expected in: /opt/subversion/lib/libapr-1.0.dylib
    /usr/sbin/apachectl: line 81: 77829 Trace/BPT trap $HTTPD $ARGV
    envvars commented out:
    httpd: Syntax error on line 103 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Symbol not found: _dav_do_find_livepropn Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.son Expected in: flat namespacen
    What I’ve got in my files currently
    —- start httpd.conf addition—-
    #SubVersioN
    # Load Subversion Apache Modules
    LoadModule dav_svn_module /opt/subversion/lib/svn-apache/mod_dav_svn.so
    # Work around authz and SVNListParentPath issue
    RedirectMatch ^(/repos/svn)$ $1/
    # Enable Subversion logging
    CustomLog logs/svn_logfile “%t %u %{SVN-ACTION}e” env=SVN-ACTION
    # Enable Subversion
    DAV svn
    # Directory containing all repository for this path
    SVNParentPath /opt/repos/svn
    # List repositories collection
    SVNListParentPath On
    #end SubVersioN
    —- end httpd.conf addition —-
    —- start /etc/envvars —-
    #The following two lines commented out to get SubVersion source control to work correctly
    #DYLD_LIBRARY_PATH=”/usr/lib:$DYLD_LIBRARY_PATH”
    #export DYLD_LIBRARY_PATH
    —- end /etc/envvars —-

  53. Well, you’ve given me an error that is more helpful than what I’ve found myself. For some reason, it appears mod_dav_svn.so is looking for an apr-util version that is older than expected but that shouldn’t be possible. I’m still working on this.

  54. Scott Hinckley says:

    I’m guessing 3 days is a bit short for your development cycle to have fixed the issue?
    Seriously though, if you need any more info from my system or want me to test a change, I’ll be glad to.

  55. Brian says:

    Hello Jeremy,
    I’ve been experiencing the same problem as Scott and I might have found a potential solution or at least some potential help in figuring out the problem?
    I had the socket sendfile error until I commented out the the two lines in envvars at which point I received errors similar to Ben back in June.
    Then I got:
    httpd: Syntax error on line 162 of /private/etc/apache2/httpd.conf: Cannot load /opt/subversion/lib/svn-apache/mod_dav_svn.so into server: dlopen(/opt/subversion/lib/svn-apache/mod_dav_svn.so, 10): Symbol not found: _dav_do_find_livepropn Referenced from: /opt/subversion/lib/svn-apache/mod_dav_svn.son Expected in: flat namespacen
    After reading through forums one led me to enable mod_dav.so and mod_dav_fs.so (which were disabled by default) and apache is starting and running after that. That might be something worth investigating.

  56. Samuel Smith says:

    Have you tested it with OS X Leopard Server. There are some notable differences between Leopard Server and Leopard. I believe Apple has some custom apache modules on Leopard Server that they don’t have on Leopard.
    Also the mucking I did was to allow xcode to work. This works just fine on Leopard so once again it may be a Leopard Server issue.

  57. Russ says:

    Hi Jeremy;
    I’m really glad that I stumbled upon this post, however I too ran into some issues with Snow Leopard. I have it kinda working but something is a bit off.
    First I am using Subversion 1.6.5, and I had to load the apache version of the mod_dav_svn.so.
    My only issue now seems to be that if I use http://localhost/repos/svn I get “Unable to load…” and a bunch of seg faults in my apache log. If I use the local ip address, http://192.168.0.2/repos/svn, it seems to work fine.
    Would you have any insight into this issue?
    Thanks,
    Russ

  58. greg willits says:

    It would be nice if this installer included a launchdaemon plist file. I’ve googled all over and so far I don’t see much consensus on how to get svnserve to launch at system startup for OS X Server. I’ve seen short files and very long files. I realize the repo folder location will have to be edited, but it would be nice to have what you considered a proper template for one.
    (p.s. also not fond of the /opt location. /usr/local would have been more idiomatic.)
    — gw

  59. A launchd plist would be a cool idea. The only issue with just giving you one is unless you created your repositories where the plist was configured, the plist wouldn’t work. I could include a plist that could be used so that you could change the repositories location and then it would just work. What do you think?
    As for /opt, there’s a reason for it. Every other Subversion client in the world uses /usr/local. SCPlugin is a great example. Me using /usr/local would mean you couldn’t install any other Subversion client that used /usr/local so no cli binary from me and SCPlugin installed at the same time. Even worse, the fact that I’ve been including ALL dependencies means any applications you used that had those deps would also be jeopardy. By standard Unix locations, /opt is for optional software and Subversion applies. I’m not sure why the location matters anyways. I document this heavily.

  60. For everyone having the ‘_apr_socket_sendfile’ problem, I found a solution, simply run:
    sudo install_name_tool -change /usr/lib/libapr-1.0.dylib /usr/lib/libapr-1.0.2.7.dylib /usr/sbin/httpd
    Which fixed the problem for me.

  61. greg willits says:

    @jeremy : From what I’ve seen as examples so far, there’s a number of details for an svn launchd plist that I’ve never seen used anywhere else, so a launchd plist as an example would be sufficient–users can edit paths. The example could go in an /extras folder or something, and clearly identified as a template. That’s good enough. No need for a plist installer IMO.
    As for /usr/local — /opt may be “standard Unix” but it is not “standard OS X.” Everything else I’ve installed from source or even binaries puts them in /usr/local. As an OS X user, that’s where I expect stuff to be. The only thing I have ever seen use /opt is MacPorts (which I don’t use because of all the duplication). I don’t understand why you’re expecting collisions when you can use /usr/local/collabnet_svn_1.6.x as a root location and symlink to /usr/local/collabnet_svn (or something) which wouldn’t clash with anything else. MySQL, Rumpus, ImageMagick and any number of *nix apps install this way. I have several versions of MySQL installed this way for compatibility testing. It doesn’t have to be /usr/local/subversion (and shouldn’t be IMO, it should be more specific as to which distro, etc). All the deps would be organized in sub-dirs indentical to how you have them now. Anyway, I’m no *nix guru, maybe I’m still missing something.

  62. Jack says:

    Thank you so much for this article it’s been really useful.
    I too suffered the libaprutil-1.0.dylib and the _apr_socket_sendfile errors on a G4 mac mini with leopard 10.5.6 and svn 1.6.6. I upgraded to 10.5.8 to see if it made any difference and it didn’t. Commenting out the envvars lines was the only way to get apache to load or so I thought.
    Checking the error log confirmed that apache doesn’t have permissions to create a log at /usr/logs/svn_logfile (which is the path your httpd snippet uses). I switched this location to match the path of the other apache log files ‘/private/var/log/apache2/svn_log’ and it all started working beautifully.
    I’ve never used OS X server but this chap (http://www.gridshore.nl/2008/12/21/upgrade-subversion-client-on-mac-osx/comment-page-1/#comment-27542) reckons users need to make a change in ServerAdmin to get the subversion binaries to work.
    ‘Solved it… obvious I suppose but you also need to update the path of dav_svn_module in ServerAdmin to point to the new module that comes with subversion install default at /opt/subversion/lib/svn-apache/mod_dav_svn.so
    Assuming you are using OS X Leopard Server.’
    Best of luck!

  63. Jack, there is a problem with Snow Leopard’s Apache modules. I’m fixing them when we release the next Subversion binary (1.6.8) by no longer building one binary for all supported OS version and instead building a binary for each OS based on OS-supplied libs.
    Greg, I will put an example launchd plist for svnserve in the next binary release.

  64. Lee Zamparo says:

    This note is for those of us experiencing the “symbol not found” error as pertaining to mod_dav_svn.so (the gory details found in /var/log/system.log or /var/log/apache2/error.log)
    The following guide at http://agileshrugged.com/blog/?p=14 has the solution: WebDav is disabled by default on Leopard & Snow Leopard AFAIK. To solve this in the GUI from the Dock:
    1) load Server Admin
    2) click on the arrow next to the entry bearing your server name in the left hand menu to expand the enabled services
    3) select Web
    4) select Sites in top menu (between Settings and Graphs)
    5) select Options in the sub menu (between General and Realms)
    6) check the WebDav box
    7) restart your server
    Keep in mind, this is for Snow Leopard (10.6.2) so the menus may be laid out differently in Leopard (10.5.X)
    Phew!

  65. Aaron says:

    Ey Jeremy,
    Would you mind taking a look at my problem described at length here: http://www.svnforum.org/2017/viewtopic.php?p=29438#29438
    You seem to be successful helping out many and it would be great if you could help me out on this one.
    Thanks,
    Aaron

  66. Aaron says:

    Nevermind I figured it out. I apparently deleted the files and needed to obtain a copy from someone with the same system version for it to work.

  67. Darrel says:

    Thank you a) for the Collab.net install bundle and b) for this tutorial.
    One note…I ran into the same issue as Chad. The updates to httpd.conf were breaking Apache due to the /usr/logs/ directory not yet existing on my local machine.
    A quick ‘sudo mkdir /usr/logs/’ fixed that.

  68. Note that if you’re using SSL (anywhere in the configuration, even if it’s not actually for your svn stuff), you need one additional line, inside the :
    SSLOptions +StdEnvVars
    Without this, you won’t get any logging to your logs/svn_logfile file.

  69. (reposted comment, due to TypePad damage):
    Note that if you’re using SSL (anywhere in the configuration, even if it’s not actually for your svn stuff), you need one additional line, inside the “Location /repos/svn” block :
    SSLOptions +StdEnvVars
    Without this, you won’t get any logging to your logs/svn_logfile file.

Leave a Reply

Your email address will not be published. Required fields are marked *

*