When a new-enough version of SQLite is detected at 'configure'-time, employ its thread-safety runtime verification.
* build/ac-macros/sqlite.m4 (SVN_LIB_SQLITE, SVN_SQLITE_CONFIG): Test whether sqlite3_threadsafe() is available, and if so, set $threadsafety_runtime_check_avail to "yes". In the former macro, record that fact by defining the SVN_HAVE_SQLITE_THREADSAFE_PREDICATE C preprocessor token.
* subversion/libsvn_fs_util/sqlite-util.c Include svn_types.h (init_sqlite): Add new function which verifies that SQLite was compiled in a thread-safe manner when SVN_HAVE_SQLITE_THREADSAFE_PREDICATE is defined. This could potentially also/alternately employ apr_dso_load() to check for SQLite DLLs which have changed since compile-time. (svn_fs__sqlite_open): Call init_sqlite(), if the library hasn't already been initialized.
In r27922, we started using the sqlite3_prepare_v2 API. However, this API was only introduced in SQLite 3.3.9, which seems to be a little too recent for comfort. This revision removes the use of sqlite3_prepare_v2, replacing it with sqlite3_prepare. This changes the semantics of the return value of sqlite3_step, so we now make sure that whenever sqlite3_step has an unexpected return value, we use sqlite3_finalize to extract a useful return value.
As a side effect, this plugs a few leaks where sqlite3_finalize calls were missing (for example, the no-rows branch in parse_mergeinfo_from_db).
* subversion/libsvn_fs_util/sqlite-util.h (svn_fs__sqlite_stmt_error): Declare new helper function.
* subversion/libsvn_fs_util/sqlite-util.c (svn_fs__sqlite_stmt_error): Implement new helper function. (svn_fs__sqlite_step_done, check_format): Use new helper function and don't use _v2 API.
* subversion/libsvn_fs_util/mergeinfo-sqlite-index.c (index_path_mergeinfo, parse_mergeinfo_from_db, get_mergeinfo_for_path, get_mergeinfo_for_path, get_mergeinfo_for_children): * subversion/libsvn_fs_util/node-origins-sqlite-index.c (get_origin, set_origin): Use new helper function and don't use _v2 API.