This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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?
Too late for 6.0, risky. Should be reevaluated and finally reviewed
Here is a proposal to eliminate use of filebased locking: http://wiki.netbeans.org/wiki/view/IOImprovementsDesc#section-IOImprovementsDesc-LightweightFileObjectOperations I'd like this to be implemented for 6.1.
First draft implemented on branch with Tag: masterfs_novcs
Fixed by merging masterfs_novcs into trunk and by following commit fixing mainly #123542 Simplify MasterFS, do not delegate on other embedded FS.