Re: [Subclipse-users] conflicts not detected during merge, exception after revert, Eclipse hang at 100% CPU

Mark Phippard schrieb:
> "Georg-W. Koltermann" <Georg.Koltermann@mscsoftware.com> wrote on
> 09/26/2006 11:03:53 AM:
> ...
>> 4. Now I wanted to switch my checkout to the newly created branch.
>> Called team switch, clicked browse for the branch and --- didn't find
>> the new branch. Oops?
>>
>> I hit refresh (F5) on the project node and also on the repository node
>> in the SVN exploring perspective, and then on a second try I could
>> successfully switch to the new branch.
>>
>
> Subclipse caches the tree within your session for performance. If you
> have already expanded the tree in some view then it will be cached and
> need to be refreshed.
>

Hi Mark,

could you, perhaps, clear the tree cache after a branch or tag has been
created?
>
>
>> 6. Got adventurous and tried a merge from another branch. It ran for a
>> while, I saw a couple conflicts scroll by in the console. I then opened
>> the synchronize view and -- oops -- found no conflicts. There were only
>> outgoing changes. Surprisingly I also found files like
>> "foo.linke-version-1234" and "foo.rechte-version-1234" for files that
>> apparently had a conflict. (I don't recall the exact names, but the file
>> names apparently were German translations of "left-version" and
>> "right-version" or some such. Yes I am using a German locale in Eclipse
>>
> :-(
>
> Conflicts produced by a Subversion merge in your working copy have nothing
> to do with the Synchronize view and would not show as conflicts in that
> view. They are decorated as conflicts in the standard views and there are
> also Problem markers added to the Problems view, including Quick Fix
> resolution actions.

Thanks for the hint. I had looked into the problems view, but could not
find anything.

I repeated the test today. It turns out the conflicts are classified as
"warning", and I routinely filter out warnings because I have so many
Java warnings in our software (missing JavaDoc, unused variables etc.
etc.). That's why I didn't see anything.

What do you think of making the merge conflicts errors instead of warnings?
> The normal procedure to fix a conflict produced by
> Subversion are to resolve the conflicts in the file using either an editor
> or the Edit Conflicts action that we supply.

The Edit Conflicts, when called on a binary file (*.so), does nothing
visible in the UI and throws this exception in the .log:

    !ENTRY org.eclipse.ui 4 0 2006-09-27 12:58:17.568
    !MESSAGE java.lang.NullPointerException
    !STACK 0
    java.lang.NullPointerException
            at org.tigris.subversion.subclipse.core.util.File2Resource.getResource(File2Resource.java:38)
            at org.tigris.subversion.subclipse.ui.actions.EditConflictsAction$1.execute(EditConflictsAction.java:151)
            at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:101)
            at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737)
            at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:113)
            at org.tigris.subversion.subclipse.ui.repository.RepositoryManager.run(RepositoryManager.java:372)
            at org.tigris.subversion.subclipse.ui.actions.SVNAction$1.run(SVNAction.java:227)
            at org.tigris.subversion.subclipse.ui.actions.SVNAction$2.run(SVNAction.java:236)
            at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.tigris.subversion.subclipse.ui.actions.SVNAction.run(SVNAction.java:233)
            at org.tigris.subversion.subclipse.ui.actions.EditConflictsAction.execute(EditConflictsAction.java:133)
            at org.tigris.subversion.subclipse.ui.actions.SVNAction.run(SVNAction.java:57)
            at org.eclipse.ui.actions.ActionDelegate.runWithEvent(ActionDelegate.java:70)
            at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:244)
            at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539)
            at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488)
            at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400)
            at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
            at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
            at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3164)
            at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2840)
            at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)

> Once they are fixed, you
> then have to take the Mark Resolved action to tell Subversion that you
> have dealt with the conflicts. This action will get rid of the left,
> right versions that Subversion created when it produced the conflict.
>

BTW, the not locked exception that I was seeing seems to stem from an
attempt to revert a symlink. At least I can reproduce it in the svn
command line by typing "svn revert
deployment/web_service_client/src/cpp/include", which is a symlink.

My remaining question was whether anyone observes erratic behavior
sometimes as well, like Eclipse hogging the CPU when subclipse is being
used.

--
Thanks for your kind help.
Regards,
Georg.