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
