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.
build 200412141900, JDK 5.0-b64 I noticed this when checked out netbeans repository and executed status on its root. Calls from OutputVisualiser.open propagate into CvsListOffline.loadEntries and deeper where it waits for I/O operation. When the result is displayed there are again similar problems with freezing UI. Filtering of statuses is done in AWT thread so my screen is not repainted for 20 seconds (PIII/800MHz/512MB).
Will check the behavior, moving to vcsgeneric module where the visualizer is implemented.
This can not be reproduced on small working directories (like single NB module - vcscore). The problem was reproduced on all NB sources. The core of the problem is, that not all data can be obtained from the output of the command. We need to find some suitable place where to put the access to CVS/Entries... The problem with freezing UI when filtering statuses can be solved by changing the cursor to WAIT cursor and do the filtering asynchronously.
The problem also is, that the *whole* tree is created even though only a few nodes are expanded. This is an extra optimization, that should be done for all recursive views.
Fixed in trunk: /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/visualizers/status/CvsStatusVisualizer.java,v <-- CvsStatusVisualizer.java new revision: 1.14; previous revision: 1.13 /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/visualizers/status/StatusInformation.java,v <-- StatusInformation.java new revision: 1.8; previous revision: 1.7 /cvs/vcsgeneric/profiles/cvsprofiles/src/org/netbeans/modules/vcs/profiles/cvsprofiles/visualizers/status/StatusTreeInfoPanel.java,v <-- StatusTreeInfoPanel.java new revision: 1.7; previous revision: 1.6
I tried it again and for a while I saw tree containing nodes - 'colors', 'sports' & 'foods' and some leafs under these + wrong label for the tree component.
The original performance problem was already fixed in 4.1. This is a sort of functional bug, that is similar to issue #55363. What we can do for 4.1, is to replace the default funny tree with some "Please Wait" node.
I would rather have that as a separate issue. It's definitely not P2, the original performance problem was solved. This is a funny functional problem, at most P3 IMHO. In real cases the funny nodes remains there for a very short time. Marking as FIXED again.
See issue #57850.