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.
could you, perhaps, clear the tree cache after a branch or tag has been
>> 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
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
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.tigris.subversion.subclipse.ui.actions.SVNAction.run(SVNAction.java:233)
> 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
Thanks for your kind help.
Received on Wed Sep 27 13:33:26 2006