Community
Participate
Working Groups
Build Identifier: 20110218-0911 E.g. I have a project called projA and that is open in my Project explorer. In the project explorer I cannot see a .svn folder (because that is hidden by default) and I am not using eclipse for svn access at all. When I select projA in the Project Explorer and click F5 (or right click and refresh) the svn status of the projA folder (on disk) is changed instantly to '~' which means "versioned item obstructed by some item of a different kind" (taken from svn help st). While I have found a way to recover my Subversion working copy after this scenario it is quite a difficult, laborious and risky process. On 2 occasions while trying to recover my Subversion working copy so that I could commit my changes I have lost all my work. Reproducible: Always Steps to Reproduce: 1.Add a project to eclipse that is in a Subversion working copy 2.Select that project folder in the Project Explorer 3.Hit F5 4.use svn st on the command line to confirm that the subversion working copy is corrupted
Which Subversion - Eclipse integration provider you are using? You'll need to open a bug against that project.
Quoting from my original report: "and I am not using eclipse for svn access at all." I have not installed nor enabled a subversion integration plugin at all. This is purely a problem with eclipse.
Also I should have Probably stated more information on my platform. I am currently running Ubuntu Linux 10.04 (LTS) on a 64 bit machine. I am using the "Eclipse IDE for JavaScript Web Developers" but as I mentioned in my previous comment this is most likely a problem with Eclipse and not with the JS "Distribution" of Eclipse. I can test this with vanilla eclipse if we think it is necessary.
Can you provide some more details as to exactly what's changing in the file system as a result of the refresh?
(In reply to comment #4) > Can you provide some more details as to exactly what's changing in the file > system as a result of the refresh? Yes I can... I ran 'du -a' before and after the refresh and here is the difference patch file: Left file: prerefresh.txt Right file: postrefresh.txt 3271d3270 < 4 ./graticulewebgis/.svn/entries 3275c3274 < 72 ./graticulewebgis/.svn --- > 68 ./graticulewebgis/.svn 4411c4410 < 71620 ./graticulewebgis --- > 71616 ./graticulewebgis 4414c4413 < 75060 . --- > 75056 . what it summarises to: doing a refresh has *deleted* the .svn/entries file!
(In reply to comment #3) > I can test this with vanilla eclipse if we > think it is necessary. I think this would be very helpful. It's hard to imagine this is something the platform is doing. We pretty much like to keep all of the user's files around.
And if possible please test with 3.7.0 instead of 3.6.2.
Ok... I've done a lot of testing and I can see now that it is not Eclipse at fault (or at least not directly). I have tested it with version 3.7 (in a new workspace directory) and there was no bug, so I tried to recreate the bug with a new workspace directory with the same Javascript version of eclipse that I have been using all along and I was *unable* to recreate the bug. So the fact is that my workspace directory has gotten corrupted in some way or there is a setting somewhere that is causing it to delete my entries file every time I refresh. The only 2 questions remain: 1) how do I "fix" my workspace so that I don't have to create a new one and 2) How did my workspace get into this situation so I can prevent it happening again!
Please test if you can make this problem happen with the standard version of Eclipse and your existing workspace. If you can, then please make a zip file of your entire workspace and attach it to the bug report. Having a workspace in this condition is bad (though I don't know how it would get into this condition). As far as how you can easily recover, you can simply export all of your projects into a zip file (select all of the projects in the project explorer and right-click Export -> General and select to Archive. Then you can import them into a clean workspace.
I'm going to resolve this as works-for-me. Please reopen this bug with more details (zipped workspace/steps to reproduce) when it happens again
(In reply to comment #10) > I'm going to resolve this as works-for-me. Please reopen this bug with more > details (zipped workspace/steps to reproduce) when it happens again Just to be clear, if you can make this happen with your damaged workspace and the you have steps, please do provide that. Don't wait for the workspace to get messed up again.
hmm... well I have tried to test this using a clean download of Eclipse Indigo, but it doesn't have the same effect. Also opening the workspace in Eclipse Indigo and then going back to by (broken) Helios seems to have fixed the problem in Helios. And on a separate point, I created a tar of the workspace folder before doing the above test so that I could restore it back to its "failing" state but after removing the workspace and untarring the archive the behaviour no longer exists! So to summarise: Failing Eclipse Helios JS (reproducible) -> open with Eclipse Classic Indigo -> No deletion of entries files -> no change to the workspace -> open with Eclipse JS Helios -> no deletion of entries file. and, Fixed Eclipse JS Helios after above steps -> move workspace "out of the way" -> untar the workspace backup made before opening with Eclipse Classic Indigo -> Open with Eclipse JS Helios -> no deletion of entries file. What a strange situation! I now consider this matter resolved but I will keep an eye on it. Thanks again for all the help.
