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.
I'm running NB on OS X and using SVN for version control. My problem is that I'm finding the Search History window to be incredibly slow, so much so that I almost always avoid it in favor of using another tool. Specifically, it's slow when working with the repository; once it has the information, doing things like diffs and reverts work as quickly as expected. Here's an example: 1. Open the Search History window for the project root, which corresponds with the repo root. 2. Leave all the search fields empty and click the Search button. The output that results is identical to what you get with the "svn log -v" option run at the root level of the same project folder but from the command line. The difference is that in the test I just ran, NB took 2:30 to produce the output, while the command line (using an svn+ssh URL, *not* a working copy) produced it so fast that I couldn't start the timer (<1s) Things don't noticeably change when I specify search options, even putting a single revision number in the From and To fields (so that NB need only pull up one revision). Also, my teammates are seeing the same problem on their comparable systems. My checked-out project is in the local file system, the repo is on a remote Linux server, and I'm using the svn+ssh protocol to get to it. Local svn client version is 1.6.2; server version is 1.4.2 (yeah, I know...). For my test project, the repo has 501 revisions and "svn log -v" on the command line produces 19757 lines of output. I didn't time it, but I just got similar performance on a new repo with just 5 revisions and about 11k files that produces about 18k lines of output. Version data: Product Version: NetBeans IDE 6.7.1 (Build 200907230233) Java: 1.6.0_15; Java HotSpot(TM) 64-Bit Server VM 14.1-b02-90 System: Mac OS X version 10.6.1 running on x86_64; MacRoman; en_US (nb) Userdir: /Users/bob/.netbeans/6.7
*** This issue has been marked as a duplicate of 175608 ***