This issue is the same as in message thread "Repository Location created for each Project when
using Team Project Sets", but that message thread didn't treat it as a bug, and didn't provide
solution steps (a generic workaround was given, but no instructions).
I'm running Eclipse 3.3.1 with Subclipse 1.2.4 on Windows XP and Sun JDK 1.5.0_11.
Reproduction Steps
- Checkout a project, not using Subclipse, e.g. svn://server/repos/project/trunk
- Create a new Eclipse workspace
- Import project into workspace
- Select: Team > Configure Branches/Tags...
The repository location is the full url, not the repository url (svn://server/repos).
With the incorrect repository location, it is impossible to create tags and branches, preventing
this feature from working. There is no way to fix the repository location through Eclipse, in
essence rendering the workspace corrupt.
Workaround / Fix-up
- Close Eclipse
- Delete file: %WORKSPACE%\.metadata\.plugins
\org.tigris.subversion.subclipse.core
\.svnProviderState
- Start Eclipse
- Select: File > Import...
- Select: Other > Checkout Projects from SVN
- Next, then select: Create a new repository location
- Next, then enter the repository location, e.g. svn://server/repos
- Next, then cancel the dialog
- Select: Team > Configure Branches/Tags...
The repository location is now correct.
This is essentially what the previous message thread meant by "If [the] repository location
already exists before you do the Import, then the [new extended] location will not be added".
Solution
The problem is in method getRepository(String location) of class
org.tigris.subversion.subclipse.core.repo.SVNRepositories.
If the repository is not already known, the current fallback is to simply use the project url as
the repository url. This may be ok for the rest of Subclipse, even though it adds a lot of
extended urls to the repository list, but it doesn't work for "Configure Branches/Tags". Once the
bad repository location has been added, there doesn't seem to be a way to remove it, other than
the workaround mentioned above which clears all repository locations.
As a fallback, the method should query subversion for the repository root, using "svn info" or the
client adapter equivalent.
This will require a communication with the subversion server, which shouldn't really be a problem
since it will only happen once (per repository), given that the information is cached for the
lifetime of the workspace.
If the server is unavailable, it could use the existing fallback as a last resort, though I
believe it should fail rather than corrupting the workspace with an bad repository location.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-02-27 20:51:23 CET