SQLite locking and FSFS rep-sharing

The FSFS rep-sharing database is an SQLite database updated
post-commit. I thought that the SQLite busy timeout would handle
concurrent updates from multiple commits but it doesn't work the way I
expected.

Start with a new repository and use gdb to interrupt the post-commit:

  $ gdb -arg svn import -mm Makefile file://`pwd`/repo/f1
  (gdb) b write_reps_to_cache
  (gdb) r
  Breakpoint 1
  (gdb) fin

That runs to the end of write_reps_to_cache so the process has written
to the database but not released the lock. Then in another terminal run:

  $ svn import -mm Makefile file://`pwd`/repo/f2
  Adding Makefile

  Committed revision 2.

  Warning: post commit FS processing had error:
  database is locked

The second commit doesn't wait for the 10 second SQLite busy timeout, it
gives the 'database is locked' error immediately.

Should we be doing more to support concurrent writes here? An explicit
loop in the post-commit? A different SQLite configuration?

-- 
Philip