Community
Participate
Working Groups
Here's a collection of exceptions and other breakages during the attempt to rename a project and a view packages inside the project: Subversive is 0.7.9.I20101203-1700 with connector 2.2.2.I20101203-1700 (Using the JavaHL 1.6 connector). -------------------- one ------------------------ org.eclipse.team.svn.core.connector.SVNConnectorException: Illegal target for the requested operation svn: Commit failed (details follow): svn: Entry for '/home/stephan/workspaces/Oliver/org.eclipse.objectteams.otequinoxdyn/src/org/eclipse/objectteams/otequinoxdyn/jplis/OTEquinoxAgent.java' is marked as 'copied' but is not itself scheduled for addition. Perhaps you're committing a target that is inside an unversioned (or not-yet-versioned) directory? at org.polarion.team.svn.connector.javahl.JavaHLConnector.handleClientException(JavaHLConnector.java:1486) at org.polarion.team.svn.connector.javahl.JavaHLConnector.commit(JavaHLConnector.java:340) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifier.commit(ThreadNameModifier.java:98) at org.eclipse.team.svn.core.operation.local.CommitOperation$2.run(CommitOperation.java:124) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doSubTask(ProgressMonitorUtility.java:118) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:154) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:149) at org.eclipse.team.svn.core.operation.local.CommitOperation.performCommit(CommitOperation.java:122) at org.eclipse.team.svn.core.operation.local.CommitOperation.runImpl(CommitOperation.java:103) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.operation.CompositeOperation.runImpl(CompositeOperation.java:95) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:39) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.ui.utility.WorkspaceModifyCancellableOperationWrapper.execute(WorkspaceModifyCancellableOperationWrapper.java:58) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118) at org.eclipse.team.svn.ui.utility.SVNTeamOperationWrapper.run(SVNTeamOperationWrapper.java:35) at org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:144) at org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:72) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: org.tigris.subversion.javahl.ClientException: Illegal target for the requested operation svn: Commit failed (details follow): svn: Entry for '/home/stephan/workspaces/Oliver/org.eclipse.objectteams.otequinoxdyn/src/org/eclipse/objectteams/otequinoxdyn/jplis/OTEquinoxAgent.java' is marked as 'copied' but is not itself scheduled for addition. Perhaps you're committing a target that is inside an unversioned (or not-yet-versioned) directory? at org.tigris.subversion.javahl.SVNClient.commit(Native Method) at org.polarion.team.svn.connector.javahl.JavaHLConnector.commit(JavaHLConnector.java:328) ... 23 more ---------------------------------------------------------- The explanation doesn't help as I was trying to commit the whole project starting at its root, not just a resource inside the project -------------------------------- two ----------------------------------- org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4091) at org.eclipse.swt.SWT.error(SWT.java:4006) at org.eclipse.swt.SWT.error(SWT.java:3977) at org.eclipse.swt.widgets.Widget.error(Widget.java:466) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:404) at org.eclipse.swt.widgets.Control.isVisible(Control.java:3179) at org.eclipse.swt.widgets.ProgressBar.timerProc(ProgressBar.java:276) at org.eclipse.swt.widgets.Display.windowTimerProc(Display.java:4377) at org.tigris.subversion.javahl.SVNClient.commit(Native Method) at org.polarion.team.svn.connector.javahl.JavaHLConnector.commit(JavaHLConnector.java:328) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifier.commit(ThreadNameModifier.java:98) at org.eclipse.team.svn.core.operation.local.CommitOperation$2.run(CommitOperation.java:124) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doSubTask(ProgressMonitorUtility.java:118) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:154) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:149) at org.eclipse.team.svn.core.operation.local.CommitOperation.performCommit(CommitOperation.java:122) at org.eclipse.team.svn.core.operation.local.CommitOperation.runImpl(CommitOperation.java:103) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.operation.CompositeOperation.runImpl(CompositeOperation.java:95) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:39) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.ui.utility.WorkspaceModifyCancellableOperationWrapper.execute(WorkspaceModifyCancellableOperationWrapper.java:58) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118) at org.eclipse.team.svn.ui.utility.SVNTeamOperationWrapper.run(SVNTeamOperationWrapper.java:35) at org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:144) at org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:72) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) --------------------------------------------------------------------- This happens frequently independent of what action I'm performing ----------------------------------three--------------------------------- org.eclipse.team.svn.core.connector.SVNConnectorException: Attempted to lock an already-locked dir here started an odyssee of trying to get the working copy into a usable state again. When I cleanup directory a it complains that directory a/b is already locked. When I select directory a/b for unlocking the Unlock operation is disabled (synchronize view), or does not offer a/b for selection (package explorer). So I cannot commit because something is locked. I cannot cleanup because something is locked. I cannot unlock, because something is not recognized as being locked. Scan for Locks showed the following behavior: 1. Freeze Eclipse while showing a dialog with only an unresponsive cancel button (I did wait a few minutes). 2. throw a variant of the above: org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4091) at org.eclipse.swt.SWT.error(SWT.java:4006) at org.eclipse.swt.SWT.error(SWT.java:3977) at org.eclipse.swt.widgets.Widget.error(Widget.java:466) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:404) at org.eclipse.swt.widgets.Control.isVisible(Control.java:3179) at org.eclipse.swt.widgets.ProgressBar.timerProc(ProgressBar.java:276) at org.eclipse.swt.widgets.Display.windowTimerProc(Display.java:4377) at org.tigris.subversion.javahl.SVNClient.status(Native Method) at org.polarion.team.svn.connector.javahl.JavaHLConnector.status(JavaHLConnector.java:408) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifier.status(ThreadNameModifier.java:608) at org.eclipse.team.svn.core.utility.SVNUtility.status(SVNUtility.java:299) at org.eclipse.team.svn.ui.operation.ScanLocksOperation$1.run(ScanLocksOperation.java:70) -------------------- 3. scan raised this exception: -------------------- java.lang.NullPointerException at org.eclipse.ui.internal.handlers.SelectAllHandler.getMethodToExecute(SelectAllHandler.java:187) at org.eclipse.ui.internal.handlers.WidgetMethodHandler.isHandled(WidgetMethodHandler.java:247) at org.eclipse.ui.internal.handlers.WidgetMethodHandler.updateEnablement(WidgetMethodHandler.java:57) at org.eclipse.ui.internal.handlers.WidgetMethodHandler$1.handleEvent(WidgetMethodHandler.java:49) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1525) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1257) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1263) at org.eclipse.swt.widgets.Control.sendFocusEvent(Control.java:3395) at org.eclipse.swt.widgets.Control.gtk_event_after(Control.java:2764) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1738) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4800) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4359) at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8256) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1239) at org.tigris.subversion.javahl.SVNClient.status(Native Method) at org.polarion.team.svn.connector.javahl.JavaHLConnector.status(JavaHLConnector.java:408) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifier.status(ThreadNameModifier.java:608) at org.eclipse.team.svn.core.utility.SVNUtility.status(SVNUtility.java:299) at org.eclipse.team.svn.ui.operation.ScanLocksOperation$1.run(ScanLocksOperation.java:70) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doSubTask(ProgressMonitorUtility.java:118) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:154) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:149) at org.eclipse.team.svn.ui.operation.ScanLocksOperation.runImpl(ScanLocksOperation.java:63) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.operation.CompositeOperation.runImpl(CompositeOperation.java:95) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:39) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:81) at org.eclipse.team.svn.ui.synchronize.action.AbstractSynchronizeLogicalModelAction$2$1.run(AbstractSynchronizeLogicalModelAction.java:344) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) ---- sorry I know I should file one bug per bug and give detailed steps for reproducing, but I can't type as fast as exceptions are occurring and I still have no clue how to get this working copy + repository back into a usable state after parts of the refactoring have been committed and the rest simply refuses to move either direction. I thought I should let you know *how* frustrating use of subversive is in the current version.
Trying to recover from the last sane state in the repository by forking a branch ("History View > right click > Branch from 851 ... > Browse") I get an empty dialog "Select Branch Location". It doesn't seem to find the existing repository location. I blindly typed in a name for the branch, having no idea what path it will land in, press OK, get the usual Invalid thread access. Switch to SVN perspective, look for the new branch, tree remains empty due to Invalid thread access. After several attempts I finally find the branch directly under "branches". Well.
Is this a new one? Got it when creating a folder in the repository: java.lang.NullPointerException at org.eclipse.ui.internal.handlers.SelectAllHandler.getMethodToExecute(SelectAllHandler.java:187) at org.eclipse.ui.internal.handlers.WidgetMethodHandler.isHandled(WidgetMethodHandler.java:247) at org.eclipse.ui.internal.handlers.WidgetMethodHandler.updateEnablement(WidgetMethodHandler.java:57) at org.eclipse.ui.internal.handlers.WidgetMethodHandler$1.handleEvent(WidgetMethodHandler.java:49) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1525) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1257) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1263) at org.eclipse.swt.widgets.Control.sendFocusEvent(Control.java:3395) at org.eclipse.swt.widgets.Control.gtk_event_after(Control.java:2764) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1738) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4800) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4359) at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8256) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1239) at org.tigris.subversion.javahl.SVNClient.mkdir(Native Method) at org.polarion.team.svn.connector.javahl.JavaHLConnector.mkdir(JavaHLConnector.java:1184) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifier.mkdir(ThreadNameModifier.java:398) at org.eclipse.team.svn.core.operation.remote.CreateFolderOperation.runImpl(CreateFolderOperation.java:90) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.operation.CompositeOperation.runImpl(CompositeOperation.java:95) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:39) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.ui.utility.DefaultCancellableOperationWrapper.run(DefaultCancellableOperationWrapper.java:55) at org.eclipse.team.svn.ui.utility.SVNTeamOperationWrapper.run(SVNTeamOperationWrapper.java:35) at org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:144) at org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:72) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Created attachment 186952 [details] crash log I knew I forgot something: it sometimes crashes hard. This time while trying to checkout a new copy of the project. Unfortunately, I can't find the crashlog this time so I'm attaching a log from a similar crash a few days ago.
another one (during update): java.lang.NullPointerException at org.eclipse.swt.widgets.Display.fixedSizeAllocateProc(Display.java:1339) at org.tigris.subversion.javahl.SVNClient.update(Native Method) at org.polarion.team.svn.connector.javahl.JavaHLConnector.update(JavaHLConnector.java:355) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifier.update(ThreadNameModifier.java:638) at org.eclipse.team.svn.core.operation.local.UpdateOperation$2.run(UpdateOperation.java:126) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doSubTask(ProgressMonitorUtility.java:118) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:154) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:149) at org.eclipse.team.svn.core.operation.local.UpdateOperation.runImpl(UpdateOperation.java:122) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.operation.CompositeOperation.runImpl(CompositeOperation.java:95) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:39) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.ui.utility.WorkspaceModifyCancellableOperationWrapper.execute(WorkspaceModifyCancellableOperationWrapper.java:58) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2313) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118) at org.eclipse.team.svn.ui.utility.SVNTeamOperationWrapper.run(SVNTeamOperationWrapper.java:35) at org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:144) at org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:72) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Similar symptom as before, but different call stack: org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4091) at org.eclipse.swt.SWT.error(SWT.java:4006) at org.eclipse.swt.SWT.error(SWT.java:3977) at org.eclipse.swt.widgets.Widget.error(Widget.java:466) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:404) at org.eclipse.swt.custom.CTabFolder.setSelectionForeground(CTabFolder.java:2962) at org.eclipse.ui.internal.presentations.PaneFolder.setSelectionForeground(PaneFolder.java:761) at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder.updateColors(DefaultTabFolder.java:467) at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder.shellActive(DefaultTabFolder.java:483) at org.eclipse.ui.internal.presentations.util.PresentablePartFolder$2.shellDeactivated(PresentablePartFolder.java:70) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:111) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1263) at org.eclipse.swt.widgets.Shell.filterProc(Shell.java:747) at org.eclipse.swt.widgets.Display.filterProc(Display.java:1537) at org.tigris.subversion.javahl.SVNClient.status(Native Method) at org.polarion.team.svn.connector.javahl.JavaHLConnector.status(JavaHLConnector.java:408) at org.eclipse.team.svn.core.extension.factory.ThreadNameModifier.status(ThreadNameModifier.java:608) at org.eclipse.team.svn.core.operation.local.RemoteStatusOperation$2.run(RemoteStatusOperation.java:147) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doSubTask(ProgressMonitorUtility.java:118) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:154) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:149) at org.eclipse.team.svn.core.operation.local.RemoteStatusOperation.runImpl(RemoteStatusOperation.java:145) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.operation.CompositeOperation.runImpl(CompositeOperation.java:95) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:39) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber.findChanges(AbstractSVNSubscriber.java:314) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber$UpdateStatusOperation$2.run(AbstractSVNSubscriber.java:349) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doSubTask(ProgressMonitorUtility.java:118) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:154) at org.eclipse.team.svn.core.operation.AbstractActionOperation.protectStep(AbstractActionOperation.java:149) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber$UpdateStatusOperation.runImpl(AbstractSVNSubscriber.java:347) at org.eclipse.team.svn.core.operation.AbstractActionOperation.run(AbstractActionOperation.java:81) at org.eclipse.team.svn.core.operation.LoggedOperation.run(LoggedOperation.java:39) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTask(ProgressMonitorUtility.java:104) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:90) at org.eclipse.team.svn.core.utility.ProgressMonitorUtility.doTaskExternal(ProgressMonitorUtility.java:81) at org.eclipse.team.svn.core.synchronize.AbstractSVNSubscriber.refresh(AbstractSVNSubscriber.java:186) at org.eclipse.team.svn.core.synchronize.UpdateSubscriber.refresh(UpdateSubscriber.java:73) at org.eclipse.team.core.subscribers.Subscriber.refresh(Subscriber.java:466) at org.eclipse.team.core.subscribers.SubscriberMergeContext.refresh(SubscriberMergeContext.java:85) at org.eclipse.team.core.mapping.provider.SynchronizationContext.refresh(SynchronizationContext.java:109) at org.eclipse.team.internal.ui.synchronize.RefreshModelParticipantJob.doRefresh(RefreshModelParticipantJob.java:69) at org.eclipse.team.internal.ui.synchronize.RefreshParticipantJob.run(RefreshParticipantJob.java:309) at org.eclipse.team.internal.ui.synchronize.RefreshModelParticipantJob.run(RefreshModelParticipantJob.java:117) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
I was hoping to get a more recent log from the crash that happens at about every other synchronize operation. Unfortunately, mostly no file is generated. Just now I see a minimal file containing nothing but: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0017b8da, pid=10852, tid=43924336 # # JRE version: 6.0_22-b04
Created attachment 187022 [details] stack dump at freeze OK, I'm now working through the refactoring by committing after about each single step in order to avoid any conflicts. Still I got into a conflicting situation (after rename one package and edit another file in another directory). In that state invoking update on one of the directories caused Eclipse to freeze at 100% CPU. See attached stack dump taken during the freeze. Only killing the process helped (couldn't even use the mouse during the freeze). Doing "svn update" on the command line worked OK and brought me back to business in this working copy.
Really... I'm in a deeeeep, a very deeeep shock, I do not quite understand how it happens, that you have got Eclipse IDE UI calls directly from the native SVN client library *.dll (or *.so for UNIX systems). :) And jokes aside - it is really frustrating situation and I have absolutely no idea about where is the actual problem. So, for now please provide some additional information: how could I perform a "rename" which would cause such a catastrophic issues? Is there any steps to reproduce? And regarding solving the issue: 1) native client throws some really strange exceptions, which leads me to idea that there could be some issues with how the library was built. In order to exclude this unknown part from the whole question you could switch to the SVN Kit-based connector. 2) obviously the working copy is damaged. Probably it is related to the "renaming" method (see question about steps to reproduce). If there is no way to restore working copy using SVN client tools, you could do backup of all you changes (just copy everything except .svn folders into the separate place), then recheckout the whole working copy and override its files with the saved ones.
(In reply to comment #8) > So, for now please provide some > additional information: how could I perform a "rename" which would cause such a > catastrophic issues? Is there any steps to reproduce? I wouldn't claim that all reported exceptions and crashes actually result from a single rename, things just escalated in this situation to the point where I couldn't keep to myself. Most likely any crashes from native code are in fact unrelated. Also the threading issues regarding SWT are likely to be unrelated. I've seen some of these exceptions an other situations, too. > And regarding solving the issue: > 1) native client throws some really strange exceptions, which leads me to idea > that there could be some issues with how the library was built. In order to > exclude this unknown part from the whole question you could switch to the SVN > Kit-based connector. I did use SVNKit until bug 260743 hit me. Until that is fixed SVNKit is not a feasible option for me, sorry. > 2) obviously the working copy is damaged. Probably it is related to the > "renaming" method (see question about steps to reproduce). If there is no way > to restore working copy using SVN client tools, you could do backup of all you > changes (just copy everything except .svn folders into the separate place), > then recheckout the whole working copy and override its files with the saved > ones. That's always the last resort, but it will destroy the history of any moved / renamed resources. Given that history across renames was my initial reason for using svn this indeed can only be the last last resort. On how to reproduce: First I suggest a configuration resembling my situation as closely as possible: - Ubuntu 10.04 - libsvn-java is 1.6.6dfsg-2ubuntu1 - Eclipse SDK 3.7 M4 - Subversive 0.7.9.I20101203-1700 - Connector (JavaHL): 2.2.2.I20101203-1700 - repository connection using https: Working in this configuration I can't remember a day when I didn't see any exceptions thrown from subversive. More specifically: I had a Plug-in project developed in the namespace org.objectteams. As this code is about to move to Eclipse *all* uses of this namespace must be refactored to org.eclipse.objectteams. Since I don't like committing inconsistent code I performed roughly these operations before starting to commit changes: - rename the project (directory, .project, META-INF/MANIFEST.MF) - rename all packages (incl. update of imports and changes in plugin.xml) - many other files had references changed, like p2.inf, *.exsd, etcpp. All renames were performed from the package explorer using a refactoring. Just now I looked into the resulting repo (eclipse crashed while browsing using the svn repository view) and discovered that renaming a project directory does not rename the folder within svn. What's the suggested gesture to make that happen?
Regarding SVN Kit issue. This week we will publish a new build which will contains the SVN Kit 1.3.5 library. In SVN Kit there were many changes done regarding SVN+SSH support (including SSH support library update), so it looks reasonable to think that there might be some positive changes. Regarding JavaHL issue. I'm not sure if there are some nasty incompatibility between the Java part and the native part, but at least their versions seems a little different: Java part in Subversive connectors - 1.6.12 and native part in your case - 1.6.6. Could be there some issues hidden?
(In reply to comment #10) > Regarding SVN Kit issue. This week we will publish a new build which will > contains the SVN Kit 1.3.5 library. In SVN Kit there were many changes done > regarding SVN+SSH support (including SSH support library update), so it looks > reasonable to think that there might be some positive changes. That'd be lovely, although http://svnkit.com/tracker/view.php?id=311 doesn't look too promising: no updates during the last 8 months. > Regarding JavaHL issue. I'm not sure if there are some nasty incompatibility > between the Java part and the native part, but at least their versions seems a > little different: > Java part in Subversive connectors - 1.6.12 > and > native part in your case - 1.6.6. > Could be there some issues hidden? Maybe? Who would know about incompatible changes in the native part? Isn't the connector checking the required version of the native library? If I knew for sure that this is the reason for at least some of the exceptions I would give it a try and switch from the latest Ubuntu LTS to the more recent (non-LTS) version, which indeed ships with libsvn-java 1.6.12
Hi, Is there any improvements on the SVN Kit side (early access site contains build 20110124-1700 with SVN Kit 1.3.5 included)?
(In reply to comment #12) > Hi, > > Is there any improvements on the SVN Kit side (early access site contains build > 20110124-1700 with SVN Kit 1.3.5 included)? Are both connectors (JavaHL and SVN Kit) using the same svn version? Last time I switched I couldn't reuse my existing workspaces due to incompatible svn working copies. That I cannot afford right now.
You are using SVN 1.6-compatible client now, right? Then you could use JavaHL 1.6.x or SVN Kit 1.3.5 - they're both works fine with the SVN 1.6 working copy format. If you're using SVN 1.5-compatible client then, of course, both - JavaHL 1.6.x and SVN Kit 1.3.5 connectors are out of scope in your case.
(In reply to comment #14) > You are using SVN 1.6-compatible client now, right? Then you could use JavaHL > 1.6.x or SVN Kit 1.3.5 - they're both works fine with the SVN 1.6 working copy > format. I have 1.6-compatible svn clients and I did play with switching back to SVNKit. However, I couldn't re-use any existing workspaces due to the issues discussed in bug 310287 comment 3 under headings "Bug 2" to "Bug 4": URLs and authentication for svn+ssh are not compatible. I'm giving up at this point. I'll stick to JavaHL for now, avoid any directory renaming if possible and switch to git after the indigo release or so. Please don't expect further information from me. Sorry folks.
After careful checking of all the reported exceptions it seems the issue grows from interaction between JavaHL 1.6 and gnome keyring: http://subclipse.tigris.org/issues/show_bug.cgi?id=889 So, there is nothing that can be done on our side.
