Community
Participate
Working Groups
Build 20021218 I had a large tree of folders (14479) and files (27128) that I tried to commit to a cvs repository that is on a local network. I'm entering this bug after 10 minutes waiting for the UI to refresh. Each time I inspect the stack of the main thread it looks like this: "main" prio=5 tid=0x00234CA0 nid=0x474 runnable [6e000..6fc40] at org.eclipse.swt.widgets.Control.getDisplay(Control.java:721) at org.eclipse.swt.widgets.Control.getDisplay(Control.java:721) at org.eclipse.swt.widgets.Control.getDisplay(Control.java:721) at org.eclipse.swt.widgets.TableItem.getDisplay(TableItem.java:203) at org.eclipse.swt.widgets.Widget.isValidThread(Widget.java:578) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:300) at org.eclipse.swt.widgets.Widget.getData(Widget.java:401) at org.eclipse.jface.viewers.TableViewer.doFindItem (TableViewer.java:143) at org.eclipse.jface.viewers.StructuredViewer.findItem (StructuredViewer.java:289) at org.eclipse.jface.viewers.CheckboxTableViewer.getChecked (CheckboxTableViewer.java:163) at org.eclipse.team.internal.ccvs.ui.ReleaseCommentDialog.getSelectedResources (ReleaseCommentDialog.java:217) at org.eclipse.team.internal.ccvs.ui.ReleaseCommentDialog.access$1 (ReleaseCommentDialog.java:213) at org.eclipse.team.internal.ccvs.ui.ReleaseCommentDialog$5.run (ReleaseCommentDialog.java:200) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:65) at org.eclipse.team.internal.ccvs.ui.ReleaseCommentDialog.okPressed (ReleaseCommentDialog.java:198) at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:240) at org.eclipse.jface.dialogs.Dialog$1.widgetSelected(Dialog.java:398) at org.eclipse.swt.widgets.TypedListener.handleEvent (TypedListener.java:87) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:825) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1692) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1410) at org.eclipse.jface.window.Window.runEventLoop(Window.java:561) at org.eclipse.jface.window.Window.open(Window.java:541) at org.eclipse.team.internal.ccvs.ui.repo.RepositoryManager$2.run (RepositoryManager.java:563) at org.eclipse.ui.internal.UIWorkspaceLock.doPendingWork (UIWorkspaceLock.java:53) at org.eclipse.ui.internal.UISynchronizer$1.run(UISynchronizer.java:23) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:31) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages (Synchronizer.java:94) - locked <05841E28> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:1669) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1414) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block (ModalContext.java:130) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:255) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run (ProgressMonitorDialog.java:351) at org.eclipse.team.internal.ccvs.ui.sync.MergeAction.run (MergeAction.java:216) at org.eclipse.team.internal.ccvs.ui.sync.MergeAction.run (MergeAction.java:123) at org.eclipse.jface.action.Action.runWithEvent(Action.java:769) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:411) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (ActionContributionItem.java:365) at org.eclipse.jface.action.ActionContributionItem.access$0 (ActionContributionItem.java:356) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent (ActionContributionItem.java:48) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:825) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1692) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1410) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1446) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1429) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539)
Did you have a large number of new resources that hadn't been added to version control yet?
Every single resource was new and not under version control.
To build the selection we call CheckboxTableViewer.getChecked(Object) for each unadded, and getChecked(Object) appears to be non-trivial cost. It might be faster to call CheckboxTableViewer.getCheckedElements() and then intersect the resulting list with unaddedResources ourselves. This would avoid one findItem() call for each unadded. However, if the set of unadded is very large (as it is in this case), we might consider a different UI treatement since the list is too large for a human to check/manage anyway. A "You have xxx new resources, do you want them added to version control?" prompt would be sufficient. This might actually be the usual way its handled, with someway of getting to the checkbox list if you really cared, like a details button.
Fix released to HEAD
