Fixing an SQLite version mismatch between Subversion and PHP5

If you are running an Apache2 server and mod_dav_svn, and you upgrade to the latest version of subversion, you might suddenly lose the ability to access newly created respositories, but still be able to access your older repositories.

When you access the new repositories, you will get:

svn: Could not open the requested SVN filesystem

And when you look in /var/log/apache/error_log, you will see:

[Wed Apr 21 15:19:18 2010] [error] [client xx.xx.xx.xx] (20014)Internal error: SQLite compiled for 3.6.11, but running with 3.3.7
[Wed Apr 21 15:19:18 2010] [error] [client xx.xx.xx.xx] Could not fetch resource information.  [500, #0]
[Wed Apr 21 15:19:18 2010] [error] [client xx.xx.xx.xx] Could not open the requested SVN filesystem  [500, #200030]
[Wed Apr 21 15:19:18 2010] [error] [client xx.xx.xx.xx] Could not open the requested SVN filesystem  [500, #200030]

Problem:

What is happening here is that the libphp5.so loaded by Apache loads its own out-of-date implementation of libsqlite. Then mod_dav_svn.so calls the sqlite functions from php instead of the libsqlite.so it was build against, and that the svn excutables on the machine are using. The real problem here is that if the repository uses a newer SQLite version, it might be unreadable when accessed by the older version.

Several people have suggested recompiling version things to fix this, either by removing one of the sqlite libraries, or linking both to the same version:

Solution:

However, there is a much simpler solution that can work — for the same reason that the older repositories work. Mod_dav_svn doesn’t seem to actually care if it’s linked against the wrong library unless the DB it is accessing uses some feature it doesn’t have access to. So if you create your new repository with a little backwards compatibility, the older SQLite can access it just fine and everyone is happy. Thus, I did the following when creating my new repo:

# svnadmin create --pre-1.6-compatible /path/to/repos

This seemed to solve the problem just fine.

Alternative Solution:

topop99 suggested another solution, which is to reorder the php5 and dav_svn modules are loaded by apache2. This presumably allows dav_svn to use the correct libsqlite before php5 comes in and ruins everything. Thus, open up httpd.conf and order the two as such:

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule php5_module modules/libphp5.so

I haven’t tried this myself, but it might be useful to someone else out there. Thanks topop99!

This entry was posted in Hardware Hacking, Projects and tagged .

6 Comments

  1. xxx
    Posted 2010-08-22 at 14:52 | Permalink

    Thanks!

  2. Posted 2010-12-16 at 14:17 | Permalink

    Man, thanks a lot!
    That issue took me all day to deal with.
    Thanks a lot (sorry for the english).

  3. jason
    Posted 2011-01-09 at 18:31 | Permalink

    Wow thank you so much this is awesome post

  4. topop99
    Posted 2011-03-15 at 02:42 | Permalink

    You are my saver!
    I spent hours on such issue, and almost wanted to give up.

    Another better(?) sulution, hinted by your above analysis:
    In httpd.conf, I saw the php5 module is loaded earlier than dav_svn. Then I switched the ordering as below, and restarted apache2 server. SVN HTTP access then work like a charm!

    LoadModule dav_svn_module modules/mod_dav_svn.so
    LoadModule php5_module modules/libphp5.so

  5. Posted 2011-03-15 at 04:16 | Permalink

    Thanks, glad I could help. Interesting alternative solution, I’ll note in the post.

  6. bward
    Posted 2013-09-24 at 16:27 | Permalink

    svnadmin create –pre-1.6-compatible /path/to/repos

    this worked for me too!

    Using subversion 1.6.17 on the server, and a 1.8 client.

One Trackback

  • […] I installed the SVN package QPKG SVN on my QNAP NAS server to have my subversion server running there. This package comes with SVN 1.6.17 . It’s easy to install via the package manager and also the brings the deamon service with it, so no further action required after NAS restarts. All my old SVN repositories were working fine. After i created a new Repository via command line i got an error message “Couldn’t open rep-cache database”. This are some version problems. Two simple fixes: […]

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*
*