Hi TMSupport,
I’ve used svnkit with eclipse since a long time and I’ve never faced any issue like this.
Our svn server version is 1.9.12, And I’m using SVNKit 1.8.14r10627 connector in my eclipse (Subversive 4.0.5). But I just cant seem to get this to work. Every time I try to commit/ update/ browse repository,
I get the error
Some resources were not updated.
svn: E210002: There was a problem while connecting to [repo url]
I am able to access and update using JavaHL but not using SVNKit.
Am I missing ay compatibility points? Any help would be appreciated in this, been stuck for weeks.
Hello,
to localize the problem could I ask you to try SVNKit command line tool? E.g.:
jsvn ls SVN_URL
Another thing I would ask you to try is to enable debug logging for SVNKit (eclipse or jsvn or both). Try FINER level and (if possible) re-try with FINEST level. The former doesn’t log network data with the latter does.
The logs should contain the exception stack traces and with FINEST level it will also contain network requests and responses, so it will be clear what’s wrong.
Hi,
Thanks for the reply.
I found something weird, I don’t have org.tmatesoft.svnkit{version} in ECLIPSE_HOME/plugins/ dir.
So I couldn’t open it in debug mode. I do have the org.tmatesoft.svnkit_1.10.1.r10777.jar though in my plugins directory.
I don’t have much experience with Eclipse. Could you try ‘jsvn’ command line utility? It shares the core with Eclipse plugin, so once we fix it, we could understand how to fix the plugin as well.
The articles about debug logging also describes how to enable debug logging for ‘jsvn’ utility.
Hi Dmitry,
I tried to run JSVN.bat but a black screen pops up and nothing happens. I have the standalone version downloaded. when I try to run via cmd, I get :
‘C:\Program’ is not recognized as an internal or external command,
operable program or batch file.
Thanks.
Sorry for the question but do you have experience with running of command line utilities via cmd? I really don’t know your background, so I don’t understand whether there’s a bug in ‘jsvn’ or its wrong usage. Normally you should ‘cd’ into ‘bin’ directory of SVNKit distribution and run ‘jsvn’ from there.
Hi,
I am using windows. I go the jsvn directory and run it from cmd. I have several files there jsvn & jsvn.bat. I open cmd in this dir and type jsvn and I get the error
“‘C:\Program’ is not recognized as an internal or external command,
operable program or batch file.”
I’m an experienced user of both eclipse and svn but this is new error I’m facing.
Please suggest.
“Program” is probably related to “Program Files” directory and a space in it. If you didn’t unpack ‘jsvn’ into “Program Files” subdirectory, it’s probably JAVA_HOME which resides there. Basically ‘jsvn.bat’ script run java.exe with SVNKit jar file. If you put JVM distribution to the directory without space character and set JAVA_HOME to it, probably this should fix the problem and you can proceed.
This really helped with the Jsvn issue. I got it to work and wrote :
jsvn ls {repo url}
This was my output:
svn: E210002: There was a problem while connecting to {server}:22
I think we can proceed with testing from jsvn as you suggested.
That’s good. Now have a look at the link that I posted twice. In " standalone application" section it proposes to create ‘logging.properties’ file.
I would suggest the following content for this file:
#
# Rename this file to logging.properties to enable SVNKit debug logging.
# Log file will reside in your working directory.
#
svnkit.level=FINEST
svnkit-network.level=FINEST
svnkit-wc.level=FINEST
svnkit-cli.level=FINEST
handlers = java.util.logging.FileHandler
java.util.logging.FileHandler.pattern = C:/path/to/svnkit.log
java.util.logging.FileHandler.limit = 0
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.append = true
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
In my example replace C:/path/to/svnkit.log with some path suitable for you. Once you create such logging.properties file, edit ‘jsvn.bat’ file in the following way. Find a line looking like:
set EXTRA_JVM_ARGUMENTS=-Djava.util.logging.config.file="%BASEDIR%\conf\logging.properties" -Dsun.io.useCanonCaches=false
then replace “%BASEDIR%\conf\logging.properties” with path to logging.properties file (prefer direct slashes ‘/’, e.g. C:/path/to/logging.properties) you’ve created before.
Now run ‘jsvn’ (once) to reproduce the problem. This will create more logging in ‘svnkit.log’ file. Make sure you have ‘svnkit.log’ with network data logged. Do NOT run ‘jsvn’ several times, to minimize relevant ‘svnkit.log’ file.
Now this ‘svnkit.log’ to some backup. Edit ‘logging.properties’ to replace FINEST with FINER everywhere. This will tell ‘jsvn’ to have less verbose logging. Again, run ‘jsvn’ to reproduce the problem. Now you’ll also have less verbose version of ‘svnkit.log’ (make sure this is so).
Finally, send/attach both files to us. We will analyze the logs and try to find out what’s wrong.
Thank you for the detailed instructions.
I’ve captured the logs and I am uploading these here.
Please let me know if there’s more input required.
svnkit_Finer.log (3.6 KB) svnkit_Finest.log (3.6 KB)
Hi Dmitry,
This issue is faced by my entire team with same error, I suppose this might be some config issue.
Appreciate your help
I think it’s both: a problem in SVNKit and config issue. Let me cite the log you’ve attached (for those who finds this discussion from search engines):
Caused by: java.io.IOException: Key exchange was not finished, connection is closed.
at com.trilead.ssh2.transport.KexManager.getOrWaitForConnectionInfo(KexManager.java:92)
at com.trilead.ssh2.transport.TransportManager.getConnectionInfo(TransportManager.java:231)
at com.trilead.ssh2.Connection.connect(Connection.java:769)
... 21 more
Caused by: java.io.IOException: Cannot negotiate, proposals do not match.
at com.trilead.ssh2.transport.KexManager.handleMessage(KexManager.java:413)
at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:765)
at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:480)
at java.base/java.lang.Thread.run(Thread.java:832)
As I understand, the SSH server and SSH client (‘trilead’ — a library used by SVNKit) communicate to agree on key exchange algorithms. Your server is set up to use algorithms that are not supported by the client. So there’re 2 solutions: 1) configure server to allow algorithms supported by the client; 2) fix the client (‘trilead’) to support those algorithms.
I’m not a specialist in SSH, but this answer recommends to edit /etc/ssh/sshd_config on the server and restart SSH server. Another answer is also about MACs option. This answer also suggests a work-around. Also have a look at Blazeflack’s post dated by 7/18/17 in this thread. So to conclude, edit /etc/ssh/sshd_config file on the SVN server machine according to the links above, this would be the quickest solution.
Another solution could come from our side. Jenkins solved similar problem by having a patched version of ‘trilead’ (and a patched version of SVNKit that uses this patched version of ‘trilead’). In particular, this commit adds " SHA256 and SHA512 HMAC algorithms" support and this change is absent in SVNKit’s version of ‘trilead’. So the solution from our side would be to port this change to SVNKit’s ‘trilead’. But I can’t promise that we will do that quickly, it would definitely take significant time.
So reconfiguring the SSH server not to use those algorithms on the server side would be the quickest work-around for you.
Hi Dmitry,
Thanks for your help throughout this.
I’ve been able to solve this by altering ssh config as mentioned in your links.
This was really helpful, Kudos!
Thanks,
/Nipun
Hello, my team and I have been experiencing this same issue for the past two weeks ever since our security has tightened up on our SVN server. Our sysadmin had to remove all MD5 and SHA1 key exchange methods and MAC methods from the sshd_config file. This has caused a huge problem as now we can’t access SVN via Eclipse and our development has pretty much halted. The trilead library only offers the key exchange methods and MAC methods that were removed. We are not allowed to modify the sshd_config file to put those methods back in. Is there any way of patching the trilead library to add the more secure methods and then patch SVNKit as mentioned in the other response from Oct 2020? I have been attempting to do this myself but without success. Any help is greatly appreciated! Thanks so much.
Hello,
there’s a patched version of the trilead library that includes newer methods but it’s a non-trivial task to incorporate those changes into SVNKit. This is because trilead version we’re using now is also patched in another way for unrelated reasons. So it’s not enough just to take Jenkins’ version of trilead but one should merge both versions.
The problem is that we don’t have resources to do that now and or in the near future, but if somebody sends us a patch solving the problem, I’ll include that change into the codebase.
Thank you so much for your response. So if I’m able to use Jenkins’ version of Trilead to help modify the version currently in SVNKit, do you happen to know how I would replace the Trilead JAR in SVNKit since I’m using it as an Eclipse plugin? Would I replace the Trilead JAR directly in the directory used for Eclipse plugins or do I insert the new JAR into SVNKit some other way? Thank you again. I’m beginning to feel there may still be hope.
If you want to go this way, consider replacing SVNKit with Jenkins-patched version as well, otherwise, I suspect, it wouldn’t work straight away. But if you replace both SVNKit and triliead, this could work in theory. This is because JavaHL API used by Eclipse is well-defined and binary compatible; and also because we care a lot about binary compatibility of other SVNKit’s APIs.
I have no experience with Eclipse plungs at all, so I can’t help you regarding that but if you find the way to replace relevant SVNKit and trilead jars, this should work.