Bugzilla – Full Text Bug Listing
| Summary: | Team-private members are marked at wrong time while importing the already shared project | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] Subversive | Reporter: | Alexander Gurov <a.gurov> | ||||
| Component: | Core | Assignee: | Igor Burilo <igor.burilo> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | groar, julien.henry, kdevolder, kresten+eclipse, mauromol | ||||
| Version: | 0.7 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Alexander Gurov
Hi Alex, Thanks for raising the bug. I'm not sure you have a reliably way of reproducing. I already have the subversive projects checked out from SVN (using subversive :-) so it is fairly easy for me to try out something for you. Let me know. Kris Created attachment 205870 [details]
Patch that fixes the issue
I've prepared a patch that seems to fix the bug for me. It is a small change, replacing the call to the scheduling operation with a call to another helper function that executes the operation immediately.
As I'm not really familiar with the code at all I would expect you will double check my patch isn't going to create other problems. (E.g. is that the right helper function to call? There seem to be couple of other similar ones).
However...
I think it is ok for the operation to be executed rather than scheduled:
- as far as I can tell the listener is only registered for PRE_BUILD events and in those events workspace changes are allowed.
- as far as I can tell the code doing the operation is executing in a context that already has workspace lock (i.e. scheduling rule on the workspace root).
This seems to fix the issue nicely for me when I tested it in a runtime workspace.
Note: unfortunately I only made this patch against a version from Friday... it seems that after pulling the changes made over the weekend I was no longer able to play/test with this in my runtime workspace, it kept asking me to configure the SVN connectors which doesn't actually work in a runtime workspace. Since I didn't know how to get around that I just reverted back to the version from before the weekend where I had no such problems.
Let me know if there's anything else I can do to help get the patch applied.
Cheers,
Kris
(In reply to comment #2) Thank you for your efforts. I will think which way is better (I've tought of slightly dfferent solution). Regarding connectors issue - it seems you're using the installed ones, but it won't work in all the cases. To be precise, next build will introduce SVN 1.7 related API changes, and that is why the old connector builds won't be compatible with the new build of the main plug-in anymore. In order to avoid the issue when you're working with the main plug-in's source code, it'll be better to checkout connectors from the polarion.org repository because they have all the required changes. (In reply to comment #3) > (In reply to comment #2) > > Thank you for your efforts. I will think which way is better (I've tought of > slightly dfferent solution). Sure... use my patch or another solution. It is entirely up to you, and you know the subversive code base much better than me, obviously. If you want me to try something out, let me know. Should be fixed now, but I can't reproduce the problem anyway (with or without this fixe). So, Kris, if it is possible, could you please check if everything are working all right in your case or not? Hi Alex,
I can try it out, but I'll need to figure out what you meant by this exactly:
> In order to avoid
> the issue when you're working with the main plug-in's source code, it'll be
> better to checkout connectors from the polarion.org repository because they
> have all the required changes.
Are these eclipse plugins I also have to checkout from svn? Can you point me at exactly which plugins and what repo?
Kris
(In reply to comment #6) Hello Kris, I've checked repository access (there were no anonymous access at the moment) and made a request to change the repository settings. Now you can fetch connectors with the repository located at http://svn.polarion.org/repos/community/Subversive/ using anonymous access (no username/password required). Thank you for your patience. Alexander. Alex, I've tried it just now. Something funny... the first time I tried it, it did *not* work. But the second time I tried it, it did. Each time, I imported a clean / freshly checked out set of projects (checked out using svn on commandline before import). Here's what seemed to happen the first time around: When I imported the projects, they were not automatically connected to SVN! i.e. I had to do an extra manual step to connect/share my imported projects. Note that I never had to do this before. The imported projects where automatically connected by the pre_build listener. Not this time however. So, I manually connected the projects (a bit tedious, since I have to do them one by one). After that I still find copied .svn folders in the project's output folder. I recon perhaps this may be because these folders were already copied by the Java builder before the projects where even connected to SVN. (Was the "team >> share" operation supposed to remove them?). I wanted to double check. So... I deleted the projects from the workspace. Deleted them from the file system. Then re-checked them out and re-imported them using my wizard. This time around everything went fine. The projects where connected automatically, and the .svn folders where not copied. Not sure why the first time was different, but it does worry me. Maybe something to do with the fact that I had not yet entered my secure storage password? I don't know. Kris I tried it again, and the behavior is reproducible. I.e. if I just start Eclipse (actually STS) anew with a brand new clean workspace, then immediately import the project... it will not ask me for my secure storage password and will not reconnect the projects automatically. Then connecting the project manually seems to remove only the top-level .svn folder but not those inside nested subfolder. With the older version of subversive, I always got asked to type my secure storage password as the project build was starting (I guess this was indirectly triggered by the pre-build listener's operations needing access). When I subsequently retry this same sequence of steps again, but without restarting STS, then everything works fine (I don't get asked for my password, but the project reconnect does happen automatically). So it seems to me that you did something that did actually fix the original issue, but some change has also been introduced that stops the listener from running he first time around. (I prefer the automatic reconnect to happen, because manually connecting lots of projects one by one is quite tedious). Also, it may be that there is another bug, in what happens when one reconnects projects that have already been built by the Java builder. This bug may have always existed but is only now revealed because the listener did not run. Kris A little bit more info. I put a breakpoint in the SVNFolderListener constructor and it looks to me that it behaves different now for me, because the plugin is for unknown reason only started later on. I.e. the listener created in the SVNTeamPlugin start method is not created because the start method is not called until some SVN functionality is used (e.g. when I click on Team >> share >> SVN). So the initial import I'm doing, which is not via SVN but via Gradle tooling, is being done before the SVN team plugin is started, and that is why the listener is not called. The password is therefore rather a symptom/result rather than the cause. Maybe changes where made that make the team plugin load later than it used to? Ah... I figured out what is going on. The reason why subversive coer plugin was loaded sooner in my earlier testing is that I had the svn.mylin plugin on my runtime configuration. This plugin gets started early on and it triggers the core svn plugin to also be started. So if the mylin plugin.svn is not installed, then svn plugin itself will startup much later. So I think the conclusion is that the bug I reported is fixed. But maybe we discovered a slightly related but different bug. It only happens if we import projects before the team.svn.core plugin has been loaded. I'm not sure how likely this scenario is, but I guess we clearly can't rule it out completely. (In reply to comment #11) Kris, thank you very much for your help! It really was the deciding moment. I was able to reproduce the issue by creating a clean workspace that could not cause any SVN-related activities and then importing an already shared project into the workspace. 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. It seems there was the issue report related to exactly the described situation: bug #336689. So, I will think of solving the issue in the scope of the forementioned issue. You're welcome to track the issue! Thank you once again. Hi Alex, Perhaps the extension point "org.eclipse.ui.startup" could be of use. Kris (In reply to comment #13) > Hi Alex, > > Perhaps the extension point "org.eclipse.ui.startup" could be of use. > > Kris Unfortunately not and there are two reasons: 1) there are "headless" configurations where UI is not involved 2) org.eclipse.ui.startup extensions could be disabled in the Eclipse IDE preferences which will leade to the same issue as before. Comment on attachment 205870 [details]
Patch that fixes the issue
Set iplog flag
*** Bug 350933 has been marked as a duplicate of this bug. *** |