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.
According to subversion 1.9 roadmap, they plan to release sometimes this year: http://subversion.apache.org/roadmap.html Subversion support in NB should be prepared and offer to switch to CLI once again when it comes accross a 1.9 WC.
seems 1.9.0 alpha works transparently at the moment, it can work with 1.8 WCs and 1.8 SvnKit and JavaHL can both work with 1.9 checkouts. So let's check when beta is out.
Subversion 1.9 is out, the working copy format is the same as 1.8, so I currently have SVN and TortoiseSVN 1.9 installed (on Windows x64 machine) and NetBeans works with it quite good via SvnKit (JavaHL doesn't work there yet). Sometimes I encounter some problems with locking of working copy when updating it from server by TortoiseSVN - there are conflicts of multiple threads accessing the wc.db (working copy cleanup with breaking the locks is then necessary). I'm not sure whether this is a bug in TortoiseSVN, or it's caused by a concurrent access of native client/TortoiseSVN and SvnKit from NetBeans.
(In reply to kalwi from comment #2) > Subversion 1.9 is out, the working copy format is the same as 1.8, so I > currently have SVN and TortoiseSVN 1.9 installed (on Windows x64 machine) > and NetBeans works with it quite good via SvnKit (JavaHL doesn't work there > yet). That's good to hear > > Sometimes I encounter some problems with locking of working copy when > updating it from server by TortoiseSVN - there are conflicts of multiple > threads accessing the wc.db (working copy cleanup with breaking the locks is > then necessary). I'm not sure whether this is a bug in TortoiseSVN, or it's > caused by a concurrent access of native client/TortoiseSVN and SvnKit from > NetBeans. Now that's bad to hear :-). What you're describing is probably the same as the reporter of bug 254867 posted: on Windows 10 he has the same problems. Are you on Win10?
> Now that's bad to hear :-). What you're describing is probably the same as > the reporter of bug 254867 posted: on Windows 10 he has the same problems. > Are you on Win10? It's Windows 7 x64, jdk1.8.0_60 (Oracle), the latest NB nightly updates. In the opposite of the bug 254867, I had problems with TortoiseSVN, not with NetBeans. My latest usecase which I remember was building of a (Maven) project in NB and meanwhile updating the same SVN working copy by TortoiseSVN (updated changes were only in other projects than the built one). TortoiseSVN updated the files correctly but it finally failed with locked files error (no specific file was mentioned). The working copy cleanup from TortoiseSVN was not possible (error with locked SQLite file occured) until the project build in NB was finished and I closed NB IDE application. There was no error in NB and the build finished correctly, also other SVN operations which I usually perform from NB (e.g. updating changes status by "Subversion > Show Changes", SVN history or diff) were without any errors. Anyway, I will try to track the SVN behaviour more thoroughly and if I had a "luck" and catch some errors with more specific technical information, I will comment it again.
You're getting an error from TortioseSVN, sure. But unfortunately NB is not so innocent as it might seem. NetBeans too eagerly listens on external file changes and every time there is a change in the file it catches it and refreshes its svn status. So in general Tortoise might fail because: 1) it starts an update - takes some time 2) when it updates the first file NetBeans catches that and steals the access to svn db in the moment 3) now Tortoise probably fails to continue because NB is reading the metadata in the meantime I will try to do something with this and let NetBeans yield the work with svn checkout until it gets focus: will handle it in bug #254867
SVN 1.9 support and JavaHL upgrade: we have to wait a while: 1) SvnClientAdapter 1.9 API is not yet ready, still work in progress 2) We need to wait for svn 1.9.3 because of this: https://github.com/apache/subversion/commit/bae2a752c110fe43a2837e10c78d82f633232319: fix for a backward incompatible change that results in JVM crashing with older JavaHL 1.8 libraries. Users with JavaHL libs in 1.8 version will not be able to use NB at all because subversion support will crach the whole JVM. SVN 1.9.3 should fix that.
Created attachment 157531 [details] draft of the upgrade patch
What is the status of this issue as svn client 1.9.3 is released a few months ago ? http://svn.apache.org/repos/asf/subversion/tags/1.9.3/CHANGES Read nothing about 1.9 support in http://wiki.netbeans.org/FaqSubversionClients Thanks
Created attachment 158922 [details] Updated patch
fix: http://hg.netbeans.org/core-main/rev/4ebf3c77d171
Integrated into 'main-silver', will be available in build *201604030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/4ebf3c77d171 User: Ondrej Vrabec <ovrabec@netbeans.org> Log: #245778 - Be prepared for svn 1.9 Updating both JavaHL and SVNKit to 1.9 support.