[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Georg-W. Koltermann <Georg.Koltermann_at_mscsoftware.com>
Date: 2006-09-26 17:03:53 CEST


my first kind of real life test with Subclipse let me run into multiple

The configuration is Ubuntu 6.06, Eclipse 3.2, subclipse 1.1.6, svn 1.4
(javahl). This is what I observed:

1. I checked out a label from a readonly mirror svn repository.
Modified a file, tried commit, observed the exception due to the fact
the repository is readonly. Fine.

2. I relocated the repository to point to the master r/w repository.
Tried to commit again, observed another exception because the source
location was a label that is configured as readonly in the dav_svn
adapter. Fine.

3. I branched off to a r/w location, using team branch/tag on the
project node in the Java perspective. Fine.

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.

5. Successfully committed my change. Fine.

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 :-(

7. I hit F5 a few times in the synchronize view, also tried to rename
the files to the corresponding English translation, but couldn't make
Eclipse/Subclipse recognize the conflicts.

8. I realized this is not getting me anywhere, so decided to revert
(team revert on the project node). It ran for a while, then gave me an
error. In .metadata/.log I could find this stack trace:

    !ENTRY org.eclipse.core.resources 2 2 2006-09-26 14:04:56.643
    !MESSAGE Save operation warnings.
    !SUBENTRY 1 org.eclipse.core.resources 2 234 2006-09-26 14:04:56.644
    !MESSAGE The project description file (.project) for gwk.SimDat-svn was missing. This file contains important information about the project. A new project description file has been created, but some information about the project may have been lost.

    !ENTRY org.tigris.subversion.subclipse.core 4 -6 2006-09-26 14:04:56.670
    !MESSAGE org.tigris.subversion.javahl.ClientException: Arbeitskopie nicht gesperrt. Dies ist wahrscheinlich ein Fehler. Bitte melden.
    svn: Kann '/home/hunter/gwk/gwk.SimDat-svn/deployment/web_service_client/src/cpp' nicht sperren

    !STACK 0
    org.tigris.subversion.svnclientadapter.SVNClientException: org.tigris.subversion.javahl.ClientException: Arbeitskopie nicht gesperrt. Dies ist wahrscheinlich ein Fehler. Bitte melden.
    svn: Kann '/home/hunter/gwk/gwk.SimDat-svn/deployment/web_service_client/src/cpp' nicht sperren

            at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.revert(AbstractJhlClientAdapter.java:879)
            at org.tigris.subversion.subclipse.core.commands.RevertResourcesCommand.run(RevertResourcesCommand.java:97)
            at org.tigris.subversion.subclipse.ui.operations.RevertOperation.execute(RevertOperation.java:49)
            at org.tigris.subversion.subclipse.ui.operations.RepositoryProviderOperation.execute(RepositoryProviderOperation.java:68)
            at org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(SVNOperation.java:89)
            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:58)
    Caused by: org.tigris.subversion.javahl.ClientException: Arbeitskopie nicht gesperrt. Dies ist wahrscheinlich ein Fehler. Bitte melden.
    svn: Kann '/home/hunter/gwk/gwk.SimDat-svn/deployment/web_service_client/src/cpp' nicht sperren

            at org.tigris.subversion.javahl.SVNClient.revert(Native Method)
            at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.revert(AbstractJhlClientAdapter.java:876)
            ... 8 more


(The English translation of the German message would be "working copy
not locked. This is probably a bug. Please report". Oh joy of

And then Eclipse sat there consuming 100% CPU. It would still respond
to the UI, but was a bit slow and continued eating CPU. Continued
eating CPU for about an hour until I got annoyed and quit Eclipse.

My colleagues told me they had sometimes seen subclipse hog the CPU as
well. They are still using the earlier versions, but are also less than
happy with the whole situation.

What is your experience with subclipse / subversion? Is this commonly
observed behavior? Should I expect I need to live with this kind of
"unexpected but possible to work around", erm, ''features''?


Received on Tue Sep 26 17:04:27 2006

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.