Community
Participate
Working Groups
Build ID: Europa Steps To Reproduce: 1. Install Europa with Subclipse 2. Use it 3. Uninstall Subclipse via "Manage configuration" 4. Install Subversive Eclipse fails to show "Share Project" option in team menu, yet does access Subversive in SVN repos exploring. Team provider is referring to Subclipse stuff. For diagnosis, I've tried finding out where this is coming from, and it seems to be somewhere in Eclipse. I've done as follows: - check there isn't a nature specified in my .project - Ensure that subclipse did uninstall - nothing in plugins or features - Revert eclipse/configuration back to the original - search .metadata in my workspace for anything referring to subclipse - restart eclipse with -clean - scratch head - bang head against wall - I can't see where on earth the reference is coming from More information: !ENTRY org.eclipse.team.core 4 0 2007-08-04 22:30:04.046 !MESSAGE Could not instantiate provider org.tigris.subversion.subclipse.core.svnnature for project zDocs. !STACK 1 org.eclipse.team.core.TeamException: Could not instantiate provider org.tigris.subversion.subclipse.core.svnnature for project zDocs. at org.eclipse.team.core.RepositoryProvider.mapNewProvider(RepositoryProvider.java:165) at org.eclipse.team.core.RepositoryProvider.mapExistingProvider(RepositoryProvider.java:235) at org.eclipse.team.core.RepositoryProvider.getProvider(RepositoryProvider.java:507) at org.eclipse.team.internal.ccvs.ui.CVSLightweightDecorator.isMappedToCVS(CVSLightweightDecorator.java:196) at org.eclipse.team.internal.ccvs.ui.CVSLightweightDecorator.decorate(CVSLightweightDecorator.java:151) ...
Okay... further searching reveals that Windows XP-64 and it's little animated dog can't even do a simple 'grep'. The culprit is the files in .plugins\org.eclipse.core.resources\.projects, which are not getting flushed or reset on a -clean... as far as I can tell, this is not the fault of another package failing to uninstall correctly... as... it's in my workspace.
The problem is that the projects in your workspace are still mapped to the Subclipse repository provider. Although it would be possible for team to remove the mapping, it is equally likely that the missing plug-in was due to an error in which case unmapping the project is not what the user would want. One option would be for you to Disconnect the projects before uninstalling Subclipse. Another option would be for Subversion to contribute and action to the Subsclipe repository provider id to offer to convert the Subclipse project to a Subversive project. Forwarding to Subversive to consider this.
Another interesting use case is that of using Project Sets (.psf) which are then shared between a team where some have Subclipse and some have Subversive, based on their personal preference. I think that the Subclipse -> Subversive migration use case is something worth seriously considering, as it's going to be more frequent. It would certainly be useful for Subversive to implement the Subclipse provider's interface, at least to the extent of offering to migrate. Otherwise, we're left with a workspace where there is nothing useful presented via the UI, and instead users have to start hunting under the hood (which took me some discovering).
Hello Michael, I tried to run following code in the Subversive plug-in startup: IProject []projects = workspace.getRoot().getProjects(); for (int i = 0; i < projects.length; i++) { RepositoryProvider.getProvider(projects[i]); } and "Share Project" action in described case become enabled. After that I checked the Team Services code and found the issue reason. Really ConfigureProjectAction.isEnabled() method refers to RepositoryProvider.isShared() method in order to detect enablement. The last also refers to another metod of RepositoryProvider class. This internal method called isMarkedAsUnshared() and it returns a state previously set by RepositoryProvider.getProvider() method. So, it looks like this situation is handled in the Team Services but by mistake incorrect method is called inside the ConfigureProjectaction.isEnabled() method and in order to solve the problem the line: if (!RepositoryProvider.isShared(selectedProjects[0])) return true; should be replaced with line: if (RepositoryProvider.getProvider(selectedProjects[0]) == null) return true; Do you agree with the proposed solution? P.S. Of course, I can include the code at the comment start into the Subversive plug-in, but I think small correction in the Team Services will be good idea.
No, I don't agree with the proposal. The purpose of this isShared method is to perform a quick test that does not instantiate any providers. The change you propose could potentially result in too much work happening in the context menu popup which must be fast. We used to use the code you propose but had to change at one time due to performance problems. I still believe that what I described in comment 2 is the right way to go.
After problem analysis we found that currently all team providers (CVS, SVN etc.) provides its own implementation of Disconnect action. At the same time all these implementations performs the same actions: 1) ask for deletion of SCM meta-information (practically marked as team-private resources if team provider works correctly) 2) if user selected "delete" option disconnect action deletes team private resources. So, regarding to this we proposes completely new solution for this and all related problems: Disconnection action should be implemented in the Team Services itself (e.g. Apply Patch action) because it is completely independed from the concrete team provider implementation. In that case user will always have ability to disconnect a projects even if corresponding team providers are uninstalled time ago.
The assertion made in comment 6 is false (i.e. not all team providers implement disconnect the same way). So, while it may be beneficial to some providers to have a general Disconnect action that does what is described in comment 6, it would be a mistake to force this on all providers.
This is excatly what I thought. Having a default implemenation of the Disconnect action (which could be even overidden if a particular provider is available) sounded like a good idea. But you have to remember that in some cases calling the generic Disconnect action may cause more trouble than good.
(In reply to comment #7) > The assertion made in comment 6 is false (i.e. not all team providers implement > disconnect the same way). Please check Tomasz proposal, it looks reasonable. > So, while it may be beneficial to some providers to have a general Disconnect action > that does what is described in comment 6, it would be a mistake to force this on all providers. But it would be fine to force this on uninstalled provider. (In reply to comment #8) > This is excatly what I thought. Having a default implemenation of the Disconnect > action (which could be even overidden if a particular provider is available) > sounded like a good idea. I agree with you: overriding of common disconnect action when some specific is required is a good idea. > But you have to remember that in some cases calling > the generic Disconnect action may cause more trouble than good. Yes, but existing situation with uninstalled providers seems much worse. Moreover if a team provider could override the generic disconnect action we will have the safe solution.
In regards to requiring providers to override a Disconnect action, the problem is backwards compatibility (i.e. this type of requirement is not backwards compatible) In regards to surfacing the action for projects mapped to non-existent providers, the problem is writing an enablement rule that detects this situation. It could be done but it is not trivial. It should be noted that this issue is really only relevant in the Subclipse/Subversive case so I don't think it would be unreasonable for Subversive to associate an action with a Subclipse project named Convert to Subversive. This solution is trivial. Why don't you want to do that?
(In reply to comment #10) > In regards to requiring providers to override a Disconnect action, the problem > is backwards compatibility (i.e. this type of requirement is not backwards > compatible) > In regards to surfacing the action for projects mapped to non-existent > providers, the problem is writing an enablement rule that detects this > situation. It could be done but it is not trivial. Hm, as for me the solution looks trivial (and very close to already implemented features like linked resources etc.): 1) next version of team provider interface should have 2 additional methods: the first method should tell if generic disconnect API is supported (by default false) and the second should return disconnection interface instance which allows to call specific disconnect action. 2) if no provider is available then generic action is used 3) if provider is available and it have no support of generic disconnect then generic action will not be used 4) if provider is available and it supports generic disconnect then get disconnection interface and: - if no disconnection interface instance returned use generic action - if disconnection interface instance is returned use it. It is right or I missed something? > It should be noted that this issue is really only relevant in the > Subclipse/Subversive case so I don't think it would be unreasonable for > Subversive to associate an action with a Subclipse project named Convert to > Subversive. This solution is trivial. Why don't you want to do that? 1) It is incorrect assertion. This issue is not relevant only to CVS which is distributed together with the Eclipse IDE packages and can't be uninstalled. For example, I used SVN for long time but now I want to move to ClearCase. I had uninstalled SVN team provider, then I installed ClearCase team provider. Try to share projects and got the same... 2) We won't that due to reason described above: the problem is common and shouldn't be solved by Subversive, Subclipse, ClearCase or anything else.
What you describe in the previous comment would result in two Disconnect actions on projects mapped to existing repository providers. For me, this is a non-starter. As for moving from SVN to Clearcase, the scenario is different as you are actually changing your repository. This would be done by an administrator and probably wouldn't even be done within Eclipse. The particular problematic scenario we are talking about is users of Subversion who want to switch from Subclipse to Subversive. Nothing is gained by generalizing the problem and the possible solutions become more complicated.
Created attachment 109198 [details] Plug-in that implements Convert to Subversive Just for fun, I implemented a Convert to Subversive action for converting Subclipse projects to Subversive projects. It is only contributed to Subclipse projects and works by unmapping all projects and then launching the subversive Share wizard. I would recommend moving this bug to the Subversive component and they can decide whether they want to incorporate this or not. As for the more general disconnect issue, we can revisit it in 4.0 if required.
Michael, I understood your vision. But nevertheless I think the proper solution is implementing of a generic disconnect action because this way is more correct from architectural point of view. Also I suppose that we can revisit this discussion later in order to implement corresponding functionality in Eclipse 4.0, as you said. This task is not so critical, as for me. Another one moment is conversion from Subclipse to Subversive. Thank you for the tool, but we think this is the wrong way when one team provider could reconnect/manage projects that are related to another team provider for some reasons. Even more, team provider task is management of projects that are connected to source control, but not a situation when competitor A tries to manage competitor B.
I disagree strongly with your statement that a generic Disconnect is the proper solution from an architectural standpoint. I believe that it is the wrong solution precisely because it goes against the current Team architecture in Eclipse. I believe that it would only be an acceptable solution if the Team architecture of Eclipse was changed in such a way that repository providers implemented a core level interface and much of the UI was generic. In fact, this is what the Eclipse 1.0 Team API looked like and it turned out to be a failure. I haven't seen any developments since then that lead me to believe it could be done successfully in 4.0.
I see no conflicts with the current Eclipse Team Services architecture and ideas. Otherwise we should recognize "Share Project" menu item in the same way. Generalization is the good way when it could be done without losses. But as I said before I don't think that this task is so important and we can simply close it as WONTFIX or INVALID if you still see no way to implement task correctly.
*** Bug 274649 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
