On 2011-11-16, at 11:37 , Aleksandr Sidorenko wrote: > On 2011-11-16, at 11:15 , Philip Martin wrote: > >> Aleksandr Sidorenko <asidore...@cashontime.com> writes: >> >>> The sqlite command worked (I see the expected output), but I suspect that's >>> because the rep-cache.db file was already there (since 1.6.12). If I move >>> it, though, the file is NOT recreated. >>> >>> greping through /proc/xxx/maps gives me the following: >>> >>> 2a96fc4000-2a97058000 r-xp 00000000 08:01 18104376 >>> /usr/local/lib/libsqlite3.so.0.8.6 >>> 2a97058000-2a97158000 ---p 00094000 08:01 18104376 >>> /usr/local/lib/libsqlite3.so.0.8.6 >>> 2a97158000-2a9715c000 rw-p 00094000 08:01 18104376 >>> /usr/local/lib/libsqlite3.so.0.8.6 >>> >>> sqlite was built with default options, but "--enable-threadsafe" defaults >>> to "yes" if it's not used, so I guess it *is* built with thread support? >> >> Try this patch: >> >> Index: subversion/libsvn_fs_fs/fs_fs.c >> =================================================================== >> --- subversion/libsvn_fs_fs/fs_fs.c (revision 1202738) >> +++ subversion/libsvn_fs_fs/fs_fs.c (working copy) >> @@ -5580,6 +5580,7 @@ >> svn_error_t *err; >> err = svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum, >> b->parent_pool); >> + SVN_ERR(err); >> /* ### Other error codes that we shouldn't mask out? */ >> if (err == SVN_NO_ERROR >> || err->apr_err == SVN_ERR_FS_CORRUPT >> >> To make the first error hard. Then try committing a file over ra_local: >> >> $ rm -rf repo && svnadmin create repo >> $ svn import -mm repo/format file://`pwd`/repo/f >> >> That should make the error explicit. > > Ok, I tried this patch, and this is the error I get: > > svn: E200030: SQLite compiled for 3.7.9, but running with 3.3.17 > > So, it seems the sqlite version I compiled is NOT getting used; it's taking > the older one. I suspect it's not looking in the right place (/usr/lib64 vs > /usr/local/lib). I'm going to investgate this.
RESOLVED. The problem was that our Apache server was loading the PHP module *before* the mod_dav_svn module, and PHP uses an old sqlite library. Reversing the load order eliminates the error (see http://www.snowbotic.com/archives/61). Thanks everyone; it really helped me pin this down!