This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I'm a experienced Netbeans user and was previously using v6.9.1 for work projects. In v6.9.1 and previous versions there was an option on the Team > Subversion > Checkout screen that allowed a user to enter a the tunnelling details. This was detailed as follows: plink.exe -l <username> -i <key_file> In v7b2 this screen has been changed to a screen which accepts the key_file and a pass phrase. This is a great move, however when I fill out the details and try to checkout/commit a project, I get an exception as follows: org.tigris.subversion.javahl.ClientException: authentication cancelled I'm getting this exception regardless of if I try the bundled windows client, or use third party clients. In v6.9.1 I used a third party client (had to since I'm using a 64bit OS). I've checked the web and the forums and tried the following suggestions: * Added putty and plink to my windows path * Editing the Subversion/config. Although I could not find this config file in my third party clients (TorticeSVN & CollabNet), I did find this file in the following folder: C:\Users\Drayton.Brown\.netbeans\7.0beta2\config\svn\config however I've found updating this file is pointless as it has no effect and is written over when you attempt to make use of subversion. I've tried various permutations of filling out the checkout screen (do you need to fill out the password and pass phrase?), with no joy. I'm sure that this issue has come up in previous releases, and the checkout screen has ended up being rolled back to the old system. What ever the solution, it has to be better than using an external svn client, since this affects the work->commit->work round trip directly. Any help much appreciated!
Attach the message log after the failed connect attempt, please. There is additional information about the type of subversion client you use (~\.netbeans\7.0beta2\var\log\messsage.log).
Created attachment 106536 [details] messages.log after subversion ssh tunneling attempt Thanks for the quick response on this ovrabec, much appreciated! Please find the requested file attached to the bug report.
Created attachment 106537 [details] messages.log after subversion ssh tunneling attempt with torticeSVN I noticed that the last log file referred to CollabNet subversion which does not support 64bit Windows, so I un-installed CollabNet and pointed Netbeans to TorticeSVN and gave it another go.
Created attachment 106538 [details] messages.log after subversion ssh tunneling attempt with bundled client I thought it would be helpful to include the logs for the bundled subversion client too, so here it is. I've noticed that all the log files include logs detailing lack of support for Windows 64bit. I'm not sure if this is the problem that I'm experiencing, however I can say that I definitely had subversion working under windows 64Bit in Netbeans v6.9.1 (and v7b1 for that matter)
Ok, so I've found a solution to my problem! After noticing this line: libsvnjavahl-1.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform I googled to see if there was a 64bit version, and found this page in the forums: http://forums.netbeans.org/ptopic30057.html I've installed SilkSVN and made another attempt. This time I got the old checkout dialog which I filled out as I used to in v7b1, and it all worked! So I'm not sure how I managed to get subversion working in v7b1 without SilkSVN, but for me this issue is no longer a problem. I'm therefore happy to have this issue closed, although I will leave this up to ovrabec since I think the SilkSVN solution is more of a work around.
Let me make this a bit clearer. NetBeans can be run with several kinds of subversion client: 1) First and most preferable is javahl client. This one is either install along with the Collabnet Subversion client or from the NetBeans update center (Bundled Subversion client). *But* the bundled client is available *only* for 32 bit Windows platform (it won't work on 64 bit). Collabnet is the second option (however your installation seems to be broken and unable to load in the IDE). However with installation of SlikSVN you fixed this and now the IDE runs with the javahl client. 2) Second option is running with svnkit. I don't want to go in the details, but let's just say it's a pure java implementation of svn client. This client operates as a fallback when javahl can't be loaded. This had been clearly your case before you fixed the installation. Since this client is written in java, it is (generally) possible for us to provide username, password, cert file and passphrase directly to the implementation without need of plink. So for those who access a repository using svn+ssh, this is the most preferable and comfortable solution Now back to your problem (failing connection attempt). I tried to connect to a repository using svn+ssh with cert/passphrase and it successfully passed. For that i needed to enter *username*, *path to a cert* and *passphrase*. Nevertheless i tried that on Linux, not Windows (and not on 64bit). Could you please run the IDE with -J-DsvnClientAdapterFactory=svnkit, open the Checkout dialog, enter the url, username, cert file and passphrase (check all those three fields at least three times) and try to connect.
Created attachment 106592 [details] messages.log after svnkit tunneling attempt As requested, I've tried to connect after starting the IDE with: -J-DsvnClientAdapterFactory=svnkit Unfortunately I was unable to connect like this, hopefully the logs will help solve the problem though :)
I added some logging, if you're willing to give this anoher try, could you download the latest dev build (http://bits.netbeans.org/download/trunk/nightly/latest/), then start the IDE with: -J-Dversioning.util.KeyringSupport.level=-1 -J-Dversioning.keyring.logpassword=true -J-Dversioning.subversion.passwordCallback.level=-1 -J-Dversioning.subversion.logpassword=true and set the password, shutdown the Then please look into the message log, search for the passphrase/password, check that it's correct and replace it with '*' and send the files to me in an email. *Remember* to replace the real passwords, they are logged in plaintext
message log with logging enabled needed