You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2014/10/24 11:49:01 UTC

JavaHL SVNRepos and the FSFS warning function

Philip Martin <ph...@wandisco.com> writes:

> The error below is caused by running the JavaHL regression tests with
> non-working SQLite support.

Moving this bit of the discussion to dev.  The SQLite rep-cache is
designed to be optional.  Force it to fail:

Index: ../src/subversion/libsvn_fs_fs/rep-cache.c
===================================================================
--- ../src/subversion/libsvn_fs_fs/rep-cache.c	(revision 1634001)
+++ ../src/subversion/libsvn_fs_fs/rep-cache.c	(working copy)
@@ -66,6 +66,8 @@ open_rep_cache(void *baton,
   const char *db_path;
   int version;
 
+  return svn_error_create(SVN_ERR_SQLITE_ERROR, NULL, "force fail");
+
   /* Open (or create) the sqlite database.  It will be automatically
      closed when fs->pool is destroyed. */
   db_path = path_rep_cache_db(fs->path, pool);

The clients can still be used:

$ svn import -mm repo/format file://`pwd`/repo/f
Adding         repo/format
DBG: ra_plugin.c: 540: Ignoring FS warning SVN_ERR_ATOMIC_INIT_FAILURE
Committing transaction...
DBG: ra_plugin.c: 540: Ignoring FS warning SVN_ERR_ATOMIC_INIT_FAILURE
Committed revision 1.

Warning: post commit FS processing had error:
Couldn't open rep-cache database
$
$ svnadmin load repo < some.dump
<<< Started new transaction, based on original revision 1
svnadmin: warning: apr_err=SVN_ERR_ATOMIC_INIT_FAILURE
svnadmin: warning: W200029: Couldn't open rep-cache database
     * editing path : f ... done.
svnadmin: warning: apr_err=SVN_ERR_ATOMIC_INIT_FAILURE
svnadmin: warning: W200029: Couldn't open rep-cache database

------- Committed revision 1 >>>
$


When the rep-cache fails FSFS invokes the warning handler and both
ra-local and svnadmin override the default warning handler with one that
prints a warning.

In contrast JavaHL's SVNRepos leaves the default warning handler in
place and the default behaviour is SVN_ERR_MALFUNCTION_NO_RETURN which
aborts the JVM.  Is that the desired behaviour?  Perhaps JavaHL should
override the default unconditionally and attempt to print a warning?
Perhaps JavaHL should provide an API to svn_fs_set_warning_func?

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*