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.
Product Version = NetBeans IDE 7.1 (Build 201112071828) Operating System = Windows XP version 5.1 running on x86, service pack 3 Java; VM; Vendor = 1.7.0_02 Runtime = Java HotSpot(TM) Client VM 22.0-b10 Subversion = version 1.7.2 (r1207936) I have tried to import new very small project into locally running Subversion server and it fails. As a work-around, same steps were attempted with NetBeans v6.9.1 running in same system and account and I was lucky to complete import. Then I came back to NetBeans 7.1 with no other problems. Steps: 1. Create new project and some java file there 2. In Projects tab, right click this project, choose command Versioning/Import into Subversion Repository 3. Enter URL (svn://localhost/repository in may case), username and password. Click Next. 4. Use suggested repository folder (utility in my case), type some memo in the field below. Click Next. 5. Dialog indicates interaction with server by using progress bar. Some short time late, dialog titled "SVN Command failed" says: SVN command returned with the following error: org.tigris.subversion.javahl.ClientException: URL 'svn://localhost/repository/JavaBizSqlGen' doesn't exist 6. Close dialog, click Finish. It leads to 99% CPU load by Subversion server (svnserve.exe), for infinite time. Server can be re-started using Windows "Computer Management" tool, quickly and with no visible reportings/damage to data. Associated findings: 1. While installling NetBeans 7.1, it proposed to import Subversion plugin from currently installed NetBeans 6.9.1. Since consequences of this step were neither clear nor explained, I denied this offer. Now, I guess it was not a good decision, I have no idea how to apply this solution now. 2. Before I tried to import project, I used Subversion on another projects with no problem, relatively long. However, operations were limited to update and commit. 3. Used version of Subversion is not one recent. Unfortunately, I see no quick way to update it. Subversion server runs as Windows service on the machine I use for NetBeans works, it loads at boot time.
Attach the messages log after the error: > SVN Command failed" says: > SVN command returned with the following error: > org.tigris.subversion.javahl.ClientException: URL > 'svn://localhost/repository/JavaBizSqlGen' doesn't exist occurs.
In second and next attempts to repeat described steps, there was found that repository folder has been really created. Two points confirm this. 1. When I click button right to repository folder name, raised dialog shows requested folder in the list, with indicated status STARTED. 2. Steps, repeated in NetBeans 6.9.1, displayed confirmation dialog, saying that repository folder already exists. I have chosen to use the folder anyway.
Correction to first description: misspelled folder name org.tigris.subversion.javahl.ClientException: URL 'svn://localhost/repository/utility' doesn't exist
(In reply to comment #3) > Correction to first description: misspelled folder name > > org.tigris.subversion.javahl.ClientException: URL > 'svn://localhost/repository/utility' doesn't exist Again, attach the messages log: http://wiki.netbeans.org/FaqLogMessagesFile so i can review the error and try to fix it.
Created attachment 115451 [details] See around line 808 Sorry, it took some time to discover location where logs reside.
OK, the IDE runs with SVNKit client - in version 1.6. That client has problems connecting to a 1.7 server via svn. We will fix it in the scope of bug #203752. In the meantime, run the IDE with -J-DsvnClientAdapterFactory=commandline to force usage of a commandline svn.exe client. *** This bug has been marked as a duplicate of bug 203752 ***
> OK, the IDE runs with SVNKit client - in version 1.6. That client has problems connecting to a 1.7 server via svn. We will fix it in the scope of bug #203752. In the meantime, run the IDE with -J-DsvnClientAdapterFactory=commandline to force usage of a commandline svn.exe client. > *** This bug has been marked as a duplicate of bug 203752 *** Thanks!