Community
Participate
Working Groups
3.6 I20101006 I have changes in about 50 projects. When I select all the projects (from the package explorer), right click and say commit, I get the following exceptions. Selecting less project does not cause this error. java.lang.IllegalArgumentException: Argument not valid at org.eclipse.swt.SWT.error(SWT.java:4049) at org.eclipse.swt.SWT.error(SWT.java:3983) at org.eclipse.swt.SWT.error(SWT.java:3954) at org.eclipse.swt.custom.SashForm.setWeights(SashForm.java:422) at org.eclipse.team.internal.ccvs.ui.wizards.CommitWizardCommitPage.createControl(CommitWizardCommitPage.java:155) at org.eclipse.jface.wizard.Wizard.createPageControls(Wizard.java:170) at org.eclipse.jface.wizard.WizardDialog.createPageControls(WizardDialog.java:675) at org.eclipse.jface.wizard.WizardDialog.createContents(WizardDialog.java:549) at org.eclipse.jface.window.Window.create(Window.java:431) at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1089) at org.eclipse.jface.window.Window.open(Window.java:790) at org.eclipse.team.internal.ccvs.ui.wizards.CommitWizard.open(CommitWizard.java:432) at org.eclipse.team.internal.ccvs.ui.wizards.CommitWizard.run(CommitWizard.java:425) at org.eclipse.team.internal.ccvs.ui.wizards.CommitWizard.run(CommitWizard.java:353) at org.eclipse.team.internal.ccvs.ui.mappings.AbstractCommitAction.execute(AbstractCommitAction.java:68) at org.eclipse.team.internal.ccvs.ui.mappings.CVSModelProviderAction.run(CVSModelProviderAction.java:129) at org.eclipse.ui.actions.BaseSelectionListenerAction.runWithEvent(BaseSelectionListenerAction.java:168) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3697) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1314) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1337) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1322) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1136) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3557) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3215) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2407) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2371) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2220) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:367) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) 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:592) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:611) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:566) at org.eclipse.equinox.launcher.Main.run(Main.java:1363)
I managed to reproduce this problem with one project. What matters is probably that I tried to commit more then a thousand of added files.
This may be caused by bug 124039.
*** Bug 301681 has been marked as a duplicate of this bug. ***
*** Bug 301789 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > *** Bug 301681 has been marked as a duplicate of this bug. *** Happened on Windows Vista so it's no longer Mac OS X specific.
*** Bug 309246 has been marked as a duplicate of this bug. ***
*** Bug 311104 has been marked as a duplicate of this bug. ***
I encountered this bug using 3.6 M7 and assumed the large commit size was the problem (around 2000) files. Tried to scale the commit back to several hundred files and still hit the problem. Not sure exactly where the line is here. I ended up reverting back to 3.5.x to commit the change. As a result I would say this is a pretty serious issue. This is a regression, and close to a major loss in functionality for CVS commit. Seems there are a lot of people hitting this bug as well. I'm not sure why this isn't on the radar to be fixed in Helios.
Upgrading to Major severity to ensure that this bug isn't overlooked, and because I think it warrants this severity.
I think the problem is the lack of reproducible steps. In my case, if memory serves me well, restarting eclipse has been enough to be back in a working state.
(In reply to comment #10) > I think the problem is the lack of reproducible steps. In my case, if memory > serves me well, restarting eclipse has been enough to be back in a working > state. I was getting this problem reliably by attempting to commit many resources (can't remember how many it was, but > 1000). In my case it was generated javadocs. Couldn't the problem be reproduced just by generating some large number of files (e.g. javadocs) and attempting to commit them?
As soon as there are a lot of outgoing changes, the commit wizard cannot be opened and it becomes a pain to commit the code. Could not the tree be collapsed by default ? To reproduce, you just need to create lot of outgoing changes (> 1000).
Could that be put on the list of things to fix for 3.6.1?
(In reply to comment #13) > Could that be put on the list of things to fix for 3.6.1? It has been already added to Workspace 3.7 Development Plan draft[1]. I agree, it does look like a perfect candidate for backporting to 3.6.1 [1] http://wiki.eclipse.org/Workspace3.7
See also bug 314549.
What is the rational behind the fully expanded tree for all outgoing changes ? I think this is the cause of the problem and this is really annoying as I have to slice the outgoing changes to be able to commit them.
*** Bug 317343 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > What is the rational behind the fully expanded tree for all outgoing changes ? I don't know the answer for this question. I guess for it saves you couple of clicks when you want to review the files to be committed. > I think this is the cause of the problem (...) If you're right I think we should consider collapsing the tree (keeping it collapsed), at least for larger commit sets.
As a temporary workaround you could increase the maximum number of files displayed in the Commit dialog (the preferences is available on Team > CVS page). It will take more time to show the dialog but at least it won't crash. I'm working on a proper fix.
Created attachment 173106 [details] Fix v01 The exception was thrown when the dialog tried to set 2 weights on a sash which contained only one child. This was caused by the fact that we didn't create part of the UI when the maximum number of changes was exceeded.
Created attachment 173107 [details] mylyn/context/zip
Tomasz, do you think this is a candidate for 3.6.1?
Yes I do, I've just created bug 318557 for doing that.
(In reply to comment #20) > Created an attachment (id=173106) [details] > Fix v01 > > The exception was thrown when the dialog tried to set 2 weights on a sash which > contained only one child. This was caused by the fact that we didn't create > part of the UI when the maximum number of changes was exceeded. Any idea when this will be released? I have more than 2000 commits to do and I am hitting this bug again.
Created attachment 174626 [details] Fix v02 Previous fix revisited. The idea stayed the same, but I decided to hide compare pane when the message about reaching the threshold is shown. An empty pane could be seen as a pain in the eye, especially when it's totally blank (see the following screenshot).
Created attachment 174628 [details] totally blank compare pane
Created attachment 174629 [details] empty compare pane
(In reply to comment #24) > Any idea when this will be released? I have more than 2000 commits to do and I > am hitting this bug again. I plan to release the latest patch tomorrow, shortly after the I-build. I'm sorry I should have done this last week. Until then you could adjust the threshold (comment 19) to a number that works for you.
Fix v02 applied to HEAD. Available in builds >=N20100720-2000.
*** Bug 320679 has been marked as a duplicate of this bug. ***
Created attachment 176463 [details] "Show Changes pane" button highlighted While verifying the bug the only thing that caught my eye was the "Show Changes pane" button. It's highlighted when the user decides to show changes when the threshold has been reached. This is not a regression though, it's been there for a while, I've seen it in 3.6M2 as well.
Verified in I20100805-1700.
*** Bug 325568 has been marked as a duplicate of this bug. ***
