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

[Subclipse-users] Should not connect when importing existing project into workspace

From: Konstantin Kolinko <knst.kolinko_at_gmail.com>
Date: Thu, 17 Jul 2008 04:08:07 +0400

I am using Eclipse 3.4 Ganymede with Subclipse 1.4.1
on Windows.

When I create an new workspace in Eclipse and import
an existing project (already managed by subversion) into
the workspace, the subclipse tries to connect to the
repository.

It should not do that. All the necessary information is already
present in the working copy. It should not contact the repository.

If you cancel the connection attempt or refuse to authenticate
to the repository, you will get a stacktrace in your eclipse log.
An analysis of it is below.

Steps to reproduce:
1. Open a new workspace in Eclipse
2. Import an existing project, that is already controlled by
subversion, into the workspace.
3. Refuse the attempts to connect to Subversion, if you are
using firewall software, or refuse to authenticate into the
repository. You are asked two times.
4. The project will have no subversion decorations on it and
has no Team page in its properties dialog. I treat is as it is
not shared.
5. Examine the .log file in your workspace directory.

Expected result:
- Do not attempt to connect to the repository, and show
decorations on the project files.

A log file from the case when connection attempts are refused
contains the following stack trace:

=======================
!STACK 1
org.tigris.subversion.subclipse.core.SVNException:
org.tigris.subversion.javahl.ClientException: RA layer request failed
svn: OPTIONS of 'https://my server/my repository': could not connect
to server (https://my server)

        at org.tigris.subversion.subclipse.core.SVNException.wrapException(SVNException.java:75)
        at org.tigris.subversion.subclipse.core.repo.SVNRepositoryLocation.fromString(SVNRepositoryLocation.java:547)
        at org.tigris.subversion.subclipse.core.repo.SVNRepositories.getRepository(SVNRepositories.java:189)
        at org.tigris.subversion.subclipse.core.resources.SVNWorkspaceRoot.setSharing(SVNWorkspaceRoot.java:209)
        at org.tigris.subversion.subclipse.core.SVNTeamProviderType$AutoShareJob.autoconnectSVNProject(SVNTeamProviderType.java:126)
        at org.tigris.subversion.subclipse.core.SVNTeamProviderType$AutoShareJob.run(SVNTeamProviderType.java:104)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.tigris.subversion.svnclientadapter.SVNClientException:
org.tigris.subversion.javahl.ClientException: RA layer request failed
svn: OPTIONS of 'https://my server/my repository': could not connect
to server (https://my server)

        at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getInfo(AbstractJhlClientAdapter.java:1814)
        at org.tigris.subversion.svnclientadapter.AbstractClientAdapter.getInfo(AbstractClientAdapter.java:229)
        at org.tigris.subversion.subclipse.core.repo.SVNRepositoryLocation.fromString(SVNRepositoryLocation.java:541)
        ... 5 more
Caused by: org.tigris.subversion.javahl.ClientException: RA layer request failed
svn: OPTIONS of 'https://my server/my repository': could not connect
to server (https://my server)

        at org.tigris.subversion.javahl.SVNClient.info2(Native Method)
        at org.tigris.subversion.javahl.SVNClient.info2(SVNClient.java:1346)
        at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.getInfo(AbstractJhlClientAdapter.java:1805)
        ... 7 more
=======================

Looking at the sources mentioned by the stack trace, I can see
that the connection attempt was caused by SVNClient.getInfo()
call made by SVNRepositoryLocation.fromString().

That call is used to get an instance of ISVNInfo for the repository url
to extract the root url part of it. But that information is already known
from the working copy!

Actually, the caller of that all, SVNWorkspaceRoot.setSharing(), already
has ISVNInfo instance containing that information.

I think that the issue can be solved by extending API of the following two
methods:
- SVNRepositories.getRepository(repositoryURL)
- SVNRepositoryLocation.fromString
to allow an ISVNInfo instance to be passed, instead of a plain string.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-07-17 02:08:19 CEST

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.