When attempting to find out what makes the javacvs module slow on checkouts,
I've discovered that the underlying reason is a problem in how the filesystem
locks files. Apparently, file-based file locking that is done by
o.n.m.masterfs.filebasedfs.fileobjects.WriteLock class is slow and
disk-intensive. This problem was apparently encountered before (issue #43278),
and solved by introducing a hack. A similar hack could work for javacvs, but
then there are also svn and other VCSs, copying directory trees from one place
to another, etc.
So, after reviewing the issue, my recommendation is to revise the whole locking
mechanism and decide, where file-based locking is unneeded and the "lightweight"
kind of locking could be used instead. Then provide API for outside parties to
do either kind of locking (currently the locks are always file-based, except
when you use the aforementioned hack).
It would also be interesting to find, why exactly file-based locking is so slow
right now. Could it be because it uses FileChannel acquired through
RandomAccessFile?