If a call to svn_fs_mergeinfo__update_index is ultimately going to be a no-op, don't perform any write operations at all.
The upshot of this change is that commits that don't change any svn:mergeinfo will no longer block (or be blocked by) commands that read from the merge tracking database.
* subversion/libsvn_fs_util/mergeinfo-sqlite-index.c (table_has_any_rows_with_rev): New helper function. (clean_tables): New helper function to do the cleanup of failed transactions, factored out of svn_fs_mergeinfo__update_index. (svn_fs_mergeinfo__update_index): Factor out clean_tables.
* subversion/libsvn_fs_util/sqlite-util.c * subversion/libsvn_fs_util/sqlite-util.h (svn_fs__sqlite_step): New helper for calling sqlite3_step when you don't know if you expect SQLITE_ROW or SQLITE_DONE.
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.