Community
Participate
Working Groups
Using GM6 on Win2K Jdk 1.4.0 Running CVSNT 1.11.1.3 (Latest download) Create repository in cvsnt. Add repository to Eclipse. Share project and point to existing. Eclipse commit all files to create first version in repository. Continue to work in Eclipse as normal. Using another tool (WinCVS and jCVS both do it), look at a file in the pository and make a change. Eclipse will now complain with the message "Resource is out of sync with the file system: /VCF/CVS/Root" if you right click any resource in the navigators from now on. A stack trace is also put in the log file (below). Solving it would be really good. I cant use Eclipse right now in a team situation until its fixed as we share code. Thoughts or workrounds would be good. Cheers, Paul !STACK 1 org.eclipse.core.internal.resources.ResourceException: Resource is out of sync with the file system: /VCF/vConnector/CVS/Entries. at org.eclipse.core.internal.localstore.FileSystemResourceManager.read (FileSystemResourceManager.java:318) at org.eclipse.core.internal.resources.File.getContents(File.java:203) at org.eclipse.core.internal.resources.File.getContents(File.java:193) at org.eclipse.team.internal.ccvs.core.util.SyncFileWriter.readLines (SyncFileWriter.java:313) at org.eclipse.team.internal.ccvs.core.util.SyncFileWriter.readAllResourceSync (SyncFileWriter.java:96) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.cacheResource SyncForChildren(EclipseSynchronizer.java:597) at org.eclipse.team.internal.ccvs.core.resources.EclipseSynchronizer.getResourceSy nc(EclipseSynchronizer.java:196) at org.eclipse.team.internal.ccvs.core.resources.EclipsePhantomSynchronizer.getRes ourceSync(EclipsePhantomSynchronizer.java:128) at org.eclipse.team.internal.ccvs.core.resources.EclipseResource.getSyncInfo (EclipseResource.java:219) at org.eclipse.team.internal.ccvs.core.resources.EclipseResource.isManaged (EclipseResource.java:178) at org.eclipse.team.internal.ccvs.ui.actions.IgnoreAction.isEnabled (IgnoreAction.java:30) at org.eclipse.team.internal.ui.actions.TeamAction.selectionChanged (TeamAction.java:188) at org.eclipse.ui.internal.PluginAction.refreshEnablement (PluginAction.java:170) at org.eclipse.ui.internal.PluginAction.selectionChanged (PluginAction.java:232) at org.eclipse.ui.internal.ObjectActionContributor.contributeObjectActions (ObjectActionContributor.java:67) at org.eclipse.ui.internal.ObjectActionContributorManager.contributeObjectActions (ObjectActionContributorManager.java:108) at org.eclipse.ui.internal.PopupMenuExtender.addObjectActions (PopupMenuExtender.java:48) at org.eclipse.ui.internal.PopupMenuExtender.menuAboutToShow (PopupMenuExtender.java:68) at org.eclipse.jface.action.MenuManager.fireAboutToShow (MenuManager.java:235) at org.eclipse.jface.action.MenuManager.handleAboutToShow (MenuManager.java:306) at org.eclipse.jface.action.MenuManager.access$0(MenuManager.java:303) at org.eclipse.jface.action.MenuManager$2.menuShown (MenuManager.java:333) at org.eclipse.swt.widgets.TypedListener.handleEvent (TypedListener.java:114) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:848) at org.eclipse.swt.widgets.Control.WM_INITMENUPOPUP(Control.java:3012) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2686) at org.eclipse.swt.widgets.Decorations.windowProc (Decorations.java:1340) at org.eclipse.swt.widgets.Display.windowProc(Display.java:1992) at org.eclipse.swt.internal.win32.OS.TrackPopupMenu(Native Method) at org.eclipse.swt.widgets.Menu.setVisible(Menu.java:903) at org.eclipse.swt.widgets.Control.WM_CONTEXTMENU(Control.java:2823) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2668) at org.eclipse.swt.widgets.Display.windowProc(Display.java:1992) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:1154) at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:152) at org.eclipse.swt.widgets.Control.WM_RBUTTONUP(Control.java:3733) at org.eclipse.swt.widgets.Control.windowProc(Control.java:2720) at org.eclipse.swt.widgets.Display.windowProc(Display.java:1992) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1221) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1289) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1177) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1160) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:775) 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:248) at org.eclipse.core.launcher.Main.run(Main.java:698) at org.eclipse.core.launcher.Main.main(Main.java:534)
Paul, as a workaround you should be able to press F5 when the navigator is the active view. This should sychronize the workbench with the file system and prevent this error from being reported. Moving to team.. they shouldn't be throwing this exception when the user right clicks on a resource, but only when the action is executed.
This is happening in the enablement code for a menu item. We definitely cannot show the error to the user because this is not appropriate for enablement code. Our choices are to log the exceptions (as we do) or eat it.
We should just eat it, provided we are informing the user of the situation when he actually does the operation.
Should consider for 2.1
Currently, we log the exception and disable the menu item. If we eat the exception and leave the menu disabled, it may be difficult for the user to determine what the problem is because they wouldn't be able to run the operation (s) that would reveal the problem. I'm tempted to do an auto-refresh of the file involved however it is probably not appropriate to do this in menu enablement code. One possibility is to eat the exception and enable the menu item, thus allowing the user to encounter the error but I am hestitant to do this because some menu items that should not have been enabled may become so. Given the above, I propose we do an auto-refresh only on the resource indicated in the exception and then rerun the enablement check.
>>If we eat the exception and leave the menu disabled, it may be difficult for >>the user to >>determine what the problem is because they wouldn't be able to run the >>operation(s) that would reveal the problem. I agree. I think the idea was: - eat the exception - on exception, return enabled=true - allow the operation to proceed. It will fail further along where the problem can be better reported.
CVS actions that work on the local file structure will now ensure that any required sync info is available before testing enablement. If the sync info is not available, the action is enabled. When actions are run, the sync info is loaded before that action is run and if an out-of-sync is detected, the user is prompted to refresh. The action enablement code is run before the action body to ensure that the action is valid. Fix released to HEAD
