Hi Greg and others,
recently I mentioned on IRC that svn from trunk refused to
update its own working copy. It would just print "Skipped '.'"
and exit normally. Turns out that in init_sqlite(), we unconditionally
check sqlite for thread-safety, and bail out if it isn't thread-safe.
Because OpenBSD's pure-userland pthread implementation sets stdin and
stdout to non-blocking, piping stdout from svn linked to libpthread to
tools which aren't using pthreads (such as 'more' and 'less') does not
work too well. So I built all dependencies and Subversion itself
without support for threads.
This caused the skipping problem to appear. Our code is currently written
with the assumption that sqlite has been compiled with support for threads.
I don't know the reason for this requirement. But I guess that we can
assume that people are clever enough not to try to use svn libraries (and
hence sqlite) in a multi-threaded application if APR has been compiled without
thread support. So in accordance with established practice elsewhere, I'd like
to wrap threading-related stuff in init_sqlite() in #if APR_HAS_THREADS,
leaving only the sqlite-version check for the single-threaded case.
The patch below does this and fixes the "Skipped '.'" problem for me.
I can now update my working copies again, and svn diff | less also
Note that I don't know yet why "svn update" was still working for
subdirectories (as in "svn update notes/") but not for the current
working directory. Could this behaviour point to a bug worth hunting down?
(init_sqlite): Wrap threading related-code in #if APR_HAS_THREADS.
--- subversion/libsvn_subr/sqlite.c (revision 39292)
+++ subversion/libsvn_subr/sqlite.c (working copy)
@@ -648,6 +648,7 @@ init_sqlite(apr_pool_t *pool)
/* SQLite 3.5 allows verification of its thread-safety at runtime.
Older versions are simply expected to have been configured with
@@ -676,6 +677,7 @@ init_sqlite(apr_pool_t *pool)
_("Could not initialize SQLite shared cache"));
+#endif /* APR_HAS_THRADS */
Received on 2009-09-14 13:51:56 CEST