Community
Participate
Working Groups
Due to severe problems with SVNkit we've switched to the JavaHL connector. Unfortunately this preference setting gets lost after IDE restarts and the SVNkit is used again.
Correction: The preference change is always forgotten *immediately* ! Even after uninstalling the SVNkit connector completely, leaving only "Native JavaHL" and "empty" in the list, I can select JavaHL, press Ok and immediately reopen the preferences to see that the choice is now "empty". As this effectively prevents us from using JavaHL connector and SVNkit is not reliable I'm incresing the severity to Major.
I have checked this in Eclipse IDE 3.6 (RCP, PDT) and 3.7 (Classic) and found out that everything works just fine. So, I can see 2 possible reasons for the described behaviour: 1) Eclipse IDE preferences store is read-only for some reason (as far as I remember, preferences are stored somewhere in the workspace in .metadata folder) 2) JavaHL connector isn't working (dynamic libraries cannot be loaded) and that is why plug-in automatically selects the only working connector. If the point number 2 is not the case, then it is definitely something around point number 1. How to solve the problem? I think the best way is to ensure that Eclipse IDE instance that is running under your credentials has write access to everything in the "<your_workspace>/.metadata" folder. P.S. If there is anything special to this issue that leads you to believe it is Subversive issue, then please help me find the way to reproduce the issue.
It's definitely not case 1) because all other SVN preferences do work, i.e. are remembered. I've even reset all files and folders to writeable as you've suggested. No success. If it's case 2) how/where can I find out what exactly the problem is? Generally, I think it's a bad behaviour to silently change user settings, even if it turns out that they are problematic. I think this justifies an open bugzilla.
Created attachment 199188 [details] Difference between bad and good What is marked with green color - it is JavaHL connector that works fine: it displays its version. What is marked with red - it is not working connector: there could be no information or some error message.
Regarding silently changing - it is better when setting is changed automatically that when you get tons of errors. The only thing I could propose - is to write message into the error log if connector should be changed automatically.
(In reply to comment #4) > Created attachment 199188 [details] > Difference between bad and good > > What is marked with green color - it is JavaHL connector that works fine: it > displays its version. > What is marked with red - it is not working connector: there could be no > information or some error message. Indeed I'm having a Windows 7 64 bit system and am trying to use the JavaHL (red) connector ;-(
(In reply to comment #5) > Regarding silently changing - it is better when setting is changed > automatically that when you get tons of errors. I completely disagree. That's against all best practices I know of. Ideally I'd get one error message if something does not work so that I have the chance to think about the alternatives. But even tons of messages would be better than silently changing the preference setting I've just chosen. That looks like a severe bug to everyone!
What we will do with the issue? Should we rename it to something like "Issues with connectors shouldn't be silenced" or something like that? P.S. Actually, just now I have found the problem as described in bug summary: "Connector preference is not remembered" in my testing environment, but it is not related to the case because this issue were introduced after last was done. So, it looks like the problem was killed before it was born, which I'm grateful to you for! :)
(In reply to comment #8) > not related to the case because this issue were introduced after last was done. Correction: "...after last build was done."
I've changed the title ;-)
This issue has been migrated to https://gitlab.eclipse.org/eclipse/subversive/subversive/-/issues/86.
