Community
Participate
Working Groups
Build Identifier: 20110204-0611 With Indigo M5, projects that have imported as existing projects don't appear as shared, even thought .svn directories are everywhere. It works like a charm with latest helios. Same Subversive version on both eclipse instances. Reproducible: Always Steps to Reproduce: Helios : 0. have your svn repo declared in the SVN Repo browser 1. checkout a project in command line 2. Import the project as an existing project 3. See the project as a shared project, every decorators being here, the Team menu being populated IndigoM5: 0. have your svn repo declared in the SVN Repo browser 1. checkout a project in command line 2. Import the project as an existing project 3. See the project as an UNshared project, NO decorator being here, the Team menu being EMPTY
Could you please specify Subversive and Subversive Connector plug-ins versions and which connector you are actually using?
Subversive SVN Team Provider (Incubation) 0.7.9.I20110124-1700 org.eclipse.team.svn.feature.group Subversive SVN Connectors 2.2.2.I20110124-1700 org.polarion.eclipse.team.svn.connector.feature.group SVNKit 1.2.2 Implementation (Optional) 2.2.2.I20110124-1700 org.polarion.eclipse.team.svn.connector.svnkit15.feature.group SVNKit 1.3.5 Implementation (Optional) 2.2.2.I20110124-1700 org.polarion.eclipse.team.svn.connector.svnkit16.feature.group SVNKit 1.3.5 Implementation being used as the default connector
I tried many times with different Eclipse versions (including Indigo M5 of course) and never even once noticed the described problem. The ways I tried to reproduce the problem: 1) As you proposed: 0. have your svn repo declared in the SVN Repo browser 1. checkout a project in command line 2. Import the project as an existing project 2) In my own way: 0. have absolutely NO svn repo declared in the SVN Repo browser 1. checkout a project in command line 2. Import the project as an existing project And each time project were successfully connected to the SVN repo automatically. So, there goes another question: which command line client are you using? Is it possible that the problem is located elsewhere?
Seems more like a local workspace misconfiguration. Whenever I tested this feature it works just fine in different Helios and Indigo versions and it seems there is no way to reproduce the issue.
I use the standard svn command comming from the subversion Ubuntu package. I installed the latest Eclipse milestone, opened a fresh workspace, imported a svn-checkedout maven project, and still no luck...
Hmm... That seems pretty strange, I just tried it once again and it worked fine. But there is a difference, I'm not a Linux user. So, could it be something platform specific? I will reopen issue until I can confirm if it exists or not on the Linux platform.
I will try to do the same on a Windows box ASAP.
Hello Brice, Finally, thanks to your and Kris De Volder's efforts, I was able to find the cause of the issue (and there was one another related issue, see bug #361831): The problem is the bundle activation policy itself. Although it is highly recommended by Eclipse.org guidelines to use the lazy activation policy, the problem is while bundle is not loaded, there are no listeners and there is no way to install them in any different way except running the plug-in code, which requires loading the bundle. The only idea I've tought of is to use the "exclude package" option and static constructors in order to handle the matter. But it is most likely to cause deadlocks while loading Eclipse IDE (through interference between the class loaders). So, in the end it seems the core plug-in should avoid usage of the lazy activation policy.
Hmm, but it seems like there is noway to change the behaviour. I'll try to check if there is a way to intercept project import under those circumstances but if there none - then I don't know what to do and may close the report as "wontfix".
It seems there is a way to solve the issue using org.eclipse.core.resources.filterMatchers extension point, but I need to check for the best one before implementing it.
The solution is not an ideal one, but it works: core plug-in starts just in time due to this extension point, so the issue is solved in that way. And there is another little plus: someone could use the filter to check on the SVN meta-information folders without referring Subversive directly. P.S. If someone could suggest something better regarding this issue - you're welcome!
Thanks a lot Alexander! That's really good news! Sorry for the lack of test on Windows, my 'ASAP' was not so soon has I would have hoped. Again, kudos to you!
Hi Alexander, is version 0.7.9.I20111119-1700 of the Subversive SVN Team Provider meant to contain this fix? Because a co-worker of mine is still seeing issues here. She has to manually attach projects after an import with the "Gradle Import Wizard" provided by Spring Tools Suite. I don't see this problem on my own, maybe because as seen by STS developer Kris De Volder, I'm using Subversive-Mylyn integration and that makes Subversive start soon (see bug 361831 comment 11). But my co-worker does not have the Mylyn integration and importing on a fresh-new workspace still shows this problem (projects not automatically attached to SVN repository).
(In reply to comment #13) Yes, it is supposed to contain the fix. But please note, that the issue is really not in the Subversive, but in the Eclipse Platform lazy loading concept itself. I just used some extension point that was supposed to start early. It's not like there are any guarantees it will work always and I don't think that the lazy loading policy will be changed just to cover this issue. Still when I checked - it worked. The only alternative I've in my mind at the moment is to ask Eclipse Platform Team to provide some extension that will be actived prior to the project import (somewhere around workspace start), although it will probably nullify the existing "lazy load policies" just due to its own existance. Or to ask to provide extension point that will react exactly to the project import. I don't know what else could be done. If anyone have any suggestions - you're welcome!
I opened an enhancement request at bug 364569. Please comment on it if you see something wrong in the bug description.
Hi Alexander, I didn't notice the new version. I just installed it, I have to "right click > Team > Share" every project, but at least they are then synchronized. thanks! Brice.
(In reply to comment #16) Thank you for checking on the issue. It seems the workaround is very unstable, unfortunately. Mauro opened the corresponding request to the Eclipse Platform Team, so I'll be waiting for an answer regarding the matter.
All the details are in bug 364569.
Fixed.
Great news Alexander! Thank you! When do you think this fix will be available on the early-access update site?
(In reply to comment #20) Hi! The fix is available in the build I've published yesterday, it's just that I've delayed the planned build for two days in order to include few more fixes.
Hi Alexander, I'm sorry to tell that this issue is not fixed at all. I'm using Eclipse 4.3.1, with Subversive 1.1.1.I20130816-1700 and JavaHL 1.7.9 connector 3.0.2.I20130808-1700. With the following steps, most projects will be imported as unshared and a Team => Share Project(s) will be needed: - start Eclipse on a fresh new workspace - close the Resource Perspective, open the Java EE Perspective - Import | Existing Projects into Worskapce - check a directory which contains many nested projects (in my case, there is a root project and about 29 other nested projects), check the option to find nested projects and import them all; do not copy projects into the workspace - once imported, only 4-5 projects are shared, the others are not I don't know if the fact that the imported projects are mostly nested is relevant or not, but I don't think so, because the projects that are correctly automatically shared can either be nested or not.
Reopening as I'm still seeing this frequently.
(In reply to Mauro Molinari from comment #23) > Reopening as I'm still seeing this frequently. Just four info, we observe same issue in egit, see bug 460018. As far as I can understand it, if team plugin is not activated before the import of multiple projects, the first imported projects are simply not properly configured. We can nicely observe that with our 130 projects workspace, and our workaround was to *explicitly* activate egit plugin on startup (from our custom plugin).
This issue has been migrated to https://gitlab.eclipse.org/eclipse/subversive/subversive/-/issues/79.
