Community
Participate
Working Groups
Hi Alexander, Thanks for your response. To try to answer your question... I don't know if it *only* happens on initial import. But it definitely happens on initial import. It also seems that once the project is put into this bad state of having the .svn folders copied to the output folder, other problems happen and it is hard to repair this broken state. It seems that on successive rebuilds, even after .svn folder have been marked team private the problem will persist (i.e. the .svn folders stick around in the output folder on successive rebuild and seem to resist removal). I have not really investigated why the broken state is hard to repair in this way. One method that seems to work, is to delete the output folders entirely from the file system (i.e. go to OS shell and delete them), and then refresh and rebuild the workspace. After this the folders are permanently gone. Though I'm not 100% sure of this, I would guess that fixing the initial checkout issue will not put the project in a broken state in the first place and the later problems will thereby also be avoided. Kris ----- Original Message ----- > Hello Kris, > > Firstly - thank you for pointing the issue. And there is a question: > is > the only time the problem happens is on the initial import of a > shared > project into a workspace? If so, then it definitely is the problem. > If > it happens on other conditions too then there could be another issue > I > should search for. > > Best regards, > Alexander Gurov. > > 22.10.2011 3:35, Kris De Volder пишет: >> Hmmm... it is starting to look more and more like a subversive bug >> to me. But I will leave the final judgment of that to you guys >> (i.e. subversive devs). >> >> Here's what I learned: >> >> 1) org.eclipse.team.svn.core.SVNFolderListener is the guy who makes >> .svn folders team private. >> >> 2) this is installed as a workspace change listener by >> org.eclipse.team.svn.core.SVNTeamPlugin >> at line 169. >> >> Here it registers to receive 'PRE_BUILD' events. I gather this >> is with intention to make sure those >> .svn folders are indeed made 'team private' before the Java >> builder executes. >> >> So that seems cool. >> >> 3) But... it seems that the SVNFolderListener *schedules* the work >> to be done rather than actually doing the work. >> >> This happens at line: 115 in SVNFolderListener. >> >> The end result is that the work *actually* only happens after >> the JavaBuilder already copied the .svn folders >> to the output folder. This is too late, because the damage is >> already done. >> >> 4) Finally, >> >> The SVNFolderListener is then causing all the copied .svn >> folders inside the project's output folders to >> also be marked 'team private'. Not sure what the effect of that >> might be, but I think it is almost certainly bad, >> and could be the reason why the Java builder is not removing >> them from the output folders on successive builds. >> >> Any thoughts? >> >> Kris >> >> ----- Original Message ----- >>> OK, I think I made some headway, at least in figuring out how its >>> supposed to >>> be done. >>> >>> Found this info: >>> >>> http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fteam.htm >>> >>> I recon that must be the mechanism subversive team provider is >>> using >>> to mark .svn >>> folders as 'do not copy' for the Java builder. >>> >>> If that's the case, now all I need to figure out is why subversive >>> isn't doing this *before* the Java builder already copied some of >>> the .svn folders to the output folder. >>> >>> Kris >>> >>> ----- Original Message ----- >>>> Hi all, >>>> >>>> Hopefully this is the right place for my question, because I've >>>> been >>>> banging my head against a problem which may be a subversive bug, >>>> or >>>> it may (more likely :-) be something stupid that I myself did in >>>> an >>>> import wizard I implemented for the Gradle STS tooling. >>>> >>>> See here for some background: >>>> >>>> https://issuetracker.springsource.com/browse/STS-2173 >>>> >>>> Trying to get to the bottom of this yesterday, I spent quite a >>>> bit >>>> of >>>> time not really getting anywhere. >>>> >>>> What I need to know to make some headway debugging this, is how >>>> does >>>> subversive stop the Java builder from copying .svn folders into >>>> the >>>> output folder? I know there's some mechanism in place that does >>>> this, and normally it does work, just in the bug reported above, >>>> it >>>> sometimes doesn't and I can't figure out why not. I'm somewhat >>>> hampered by the fact that I don't know where to look for this >>>> mechanism. >>>> >>>> If someone could point me to the right place in the subversive >>>> code >>>> base that implements this filtering mechanism I can spend some >>>> more >>>> time with the debugger to try to get to the bottom of it. >>>> >>>> Any help much appreciated. >>>> >>>> Cheers, >>>> >>>> Kris
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. ***
