Hello Jakob, Excuse me for the delay with this reply.
> 1. According to the test found in SVNJNAUtil.isJNAPresent() JNA is present in > my build. > > 2. I have controlled that my login and password are in my keychain (After > all it works > fine with the 1.3.5 build). So it's not missing JNA library and it's not Keychain access problem. Unfortunately there are too many unstable changes in trunk which could lead to such behavior. If this problem is critical for you, it makes a lot of sense to use the latest stable versions, i.e. 1.3.x branch, instead of trunk. I've also created an issue in our tracker, you may find it here — http://issues.tmatesoft.com/issue/SVNKIT-6. > 3. I have created a test-app that can be downloaded here: > www.jakobnielsen.net/etc/svnkit-test.zip We're already using gradle + maven for trunk, but we decided to postpone applying the same scheme to 1.3.x branch. Here is the corresponding issue — http://issues.tmatesoft.com/issue/SVNKIT-3. Once we have snapshot builds for 1.3.x branch we will try to run the your code against the stable versions. > I do not like the "Unsupported working copy format" at all? I think it's expected message since your working copy seems to be in 1.6 format. To my knowledge Subversion 1.7 doesn't bump format version automatically. > I will set up a > svn:/-test soon if this doesn't give you enough answers. There are a few options how to localize the problem: 1. Try 1.3.x build. As I already mentioned there are no maven artifacts so far, but you may use available jars. 2. Try svn:// protocol to ensure the issue relates to HTTP authentication mechanism. 3. Try 'jsvn' utility from 1.7.0-alpha to check if there are certain problems with initialization of authentication manager. > I might also create a Maven build file so that I can test against a trunk > build. Do you mean that pom.xml located in svnkit-test archive? Semen Vadishev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! On 8 May 2011 18:34, lazee wrote: > 1. According to the test found in SVNJNAUtil.isJNAPresent() JNA is present in > my build. > > 2. I have controlled that my login and password are in my keychain (After > all it works > fine with the 1.3.5 build). > > 3. I have created a test-app that can be downloaded here: > www.jakobnielsen.net/etc/svnkit-test.zip > > The output from the app when running on 1.3.5 (Works fine): > > 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! > 53 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: Keep-Alive timeout > detected > 323 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 706 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 907 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 1217 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 1831 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 1860 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2343 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2344 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 2854 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 2855 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3029 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3469 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3471 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 3981 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 3983 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 4492 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 4493 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 4498 [Tester.main()] DEBUG InfoHandler - HandleInfo: > org.tmatesoft.svn.core.wc.SVNInfo@4d12ee4f > 4498 [Tester.main()] DEBUG InfoHandler - Setting repository info > 4499 [Tester.main()] DEBUG Tester - Got info. Basedir : /people/jakob/test > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESSFUL > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 11 seconds > [INFO] Finished at: Sun May 08 18:26:50 CEST 2011 > [INFO] Final Memory: 17M/265M > [INFO] > ------------------------------------------------------------------------ > > > The output from the app when running on the 1.7.0-SNAPSHOT (Doesn't > work): > > 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! > 23 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 27 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported > working copy format > 265 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 266 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 404 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 816 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT > 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output > stream requested... > 992 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ > 993 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: svn: > Authentication required for '<http://svn.something.no:80> SVN' > 995 [Tester.main()] DEBUG Tester - SVNException: > org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication > required for '<http://svn.something.no:80> SVN' > org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication > required for '<http://svn.something.no:80> SVN' > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) > at > org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:565) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) > at > org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) > at > org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) > at > org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) > at > org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) > at > org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) > at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) > at Tester.getRepositoryInfo(Tester.java:45) > at Tester.run(Tester.java:39) > at Tester.main(Tester.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291) > at java.lang.Thread.run(Thread.java:680) > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESSFUL > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 6 seconds > [INFO] Finished at: Sun May 08 18:14:31 CEST 2011 > [INFO] Final Memory: 17M/265M > [INFO] > ------------------------------------------------------------------------ > > > > I do not like the "Unsupported working copy format" at all? I will set up a > svn:/-test soon if this doesn't give you enough answers. > > I might also create a Maven build file so that I can test against a trunk > build. > > > Best regards > > Jakob Vad Nielsen > > > Semyon Vadishev wrote: >> I have tested 'jsvn' utility from 1.7.0 build on my OS X 10.5.8 and it >> worked just fine. >> >> There are certain differences between 1.3.5 and 'maven' branch (maven >> artifacts built from this branch, which is approximately trunk), but >> there are no API changes. >> >> I'm afraid the problem is somehow related to maven dependencies — SVNKit >> fails to access OS X Keychain with no JNA binaries at runtime. Could you >> check that JNA library is in classpath when you running the code. Debug >> log would be helpful here. Find the description how to get it here — >> https://wiki.svnkit.com/Troubleshooting. >> >> There are also internal changes, especially those related to HTTP >> authentication mechanisms. If that possible, could you please test >> authentication against some svnserve daemon, i.e. using svn:// protocol, >> not http://. >> >> If all above is not relevant for your particular case, let's see what >> could be wrong with the code. So, you have login and password stored in >> the keychain, right? Please ensure you do — find "<http://svn.api.no:80> >> SVN" item and check that access to the item is granted for Java >> applications. Otherwise it's not clear for me how do you provide the >> credentials for the corresponding realm. >> >> As I can see, you use the authentication manager which by default don't >> have any callback to provide necessary credentials, that means this >> authentication manager uses cached version of credentials. That means >> 1.3.5 build can read this cached data, but 1.7.0 version is not able to >> do that, thus we have a bug. >> >> Not to bother you with such non-stable builds, you might want to wait >> until we merge gradle/maven changes back to trunk and 1.3.x branches. So >> you can try pure trunk version or pre-release 1.3.6 build soon. >> >> Also you may try old-school jar-based way. You can download necessary >> jars from our build server — 1.3.x >> https://teamcity.svnkit.com/repository/download/bt22/14050:id/deploy/org.tmatesoft.svn_1.3.5.7590.standalone.zip >> and trunk >> https://teamcity.svnkit.com/repository/download/bt3/14080:id/deploy/org.tmatesoft.svn_1.4.0.7613.standalone.zip. >> Log in as a guest if prompted. >> >> Thank you. >> >> Semen Vadishev, >> TMate Software, >> http://svnkit.com/ - Java [Sub]Versioning Library! >> http://sqljet.com/ - Java SQLite Library! >> >> >> On 3 May 2011 20:27, lazee wrote: >>> This is the way I initialize the client: >>> >>> clientManager = SVNClientManager.newInstance(); >>> SVNRepositoryFactoryImpl.setup(); >>> if (log.isDebugEnabled()) { >>> SvnDebugLogger.initSvnDebugLogger(); >>> } >>> DAVRepositoryFactory.setup(); >>> FSRepositoryFactory.setup(); >>> >>> >>> >>> lazee wrote: >>>> Thnx, I have now done some testing on 1.7.0-SNAPSHOT. >>>> >>>> It seems that the Keychain support on Mac OSX (10.6.7) doesn't work >>>> anymore. With SvnKit 1.3.5 I am able to work against a local test >>>> repository. With 1.7.0-SNAPSHOT I get this error: >>>> >>>> SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: >>>> Authentication required for '<http://svn.api.no:80> SVN' >>>> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >>>> required for '<http://svn.api.no:80> SVN' >>>> at >>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) >>>> at >>>> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) >>>> at >>>> org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:564) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) >>>> at >>>> org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) >>>> at >>>> org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) >>>> at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) >>>> >>>> >>>> Any changes in the API that I should be aware of? >>>> >>>> >>>> >>>> Semyon Vadishev wrote: >>>>> Hi, >>>>> >>>>>> 1. It would be nice if you've had a Maven repository with nightly >>>>>> builds. >>>>>> This would have made it much easier to test this. >>>>> Agree. We're currently migrating to gradle, as a build tool, and >>>>> Sonatype Nexus, as artifact repository, for all our projects. I think >>>>> we >>>>> will set up the environment in a week or two, so we will publish >>>>> nightly >>>>> builds as maven artifacts soon. We will release SVNKit 1.3.6 with GNOME >>>>> Keyring support and some other enhancements a bit later. >>>>> >>>>> Meanwhile you may try builds from our trunk which are already in Maven >>>>> repository — >>>>> http://maven.tmatesoft.com/index.html#nexus-search;quick~svnkit. They >>>>> are no stable yet, but they do support GNOME keyring. The description >>>>> from my first email of the thread is still valid for these builds. >>>>> >>>>> If you're going to test authentication cache only, it's much safer to >>>>> use remote operations — ls, info, etc. >>>>> >>>>>> 2. When do you expect 1.4.0 to be released? >>>>> Usually we roll out the major release in a month after Subversion >>>>> release. According to Subversion roadmap — >>>>> http://subversion.apache.org/roadmap.html, there is certain features >>>>> development still in progress. So we don't have schedule yet. >>>>> >>>>> The most important feature of svn 1.7 is a new working copy format with >>>>> central metadata storage. It's based on SQLite database engine and >>>>> we've >>>>> already implemented basic support for this new storage. That means that >>>>> first builds with full support of working copy operations will appear >>>>> in >>>>> reasonable time after Subversion release. >>>>> >>>>> At the same time there are also enhancement in FSFS backend and >>>>> HTTP/DAV >>>>> repository access. Some of them are backward compatible with the former >>>>> versions. Probably we will roll out these particular improvements in >>>>> minor releases after the major one. >>>>> >>>>> Please notice that the next major version of SVNKit is 1.7.0. We >>>>> decided >>>>> to have the major version number similar to Subversion one. >>>>> >>>>> Thank you for your feedback. >>>>> >>>>> Semen Vadishev, >>>>> TMate Software, >>>>> http://svnkit.com/ - Java [Sub]Versioning Library! >>>>> http://sqljet.com/ - Java SQLite Library! >>>>> >>>>> >>>>> >>>>> On 3 May 2011 14:45, lazee wrote: >>>>>> Semyon Vadishev wrote: >>>>>>> Hello everyone, >>>>>>> >>>>>>> Some time ago we've implemented experimental GNOME Keyring support >>>>>>> for >>>>>>> SVNKit. Generally it allows to keep any sensitive data (passwords, >>>>>>> certificate passphrases, etc) in GNOME Keyring. >>>>>>> >>>>>>> We've already done some internal testing and now we decided to ask >>>>>>> the >>>>>>> community to adopt the existing code for your needs and test it as >>>>>>> well. >>>>>>> >>>>>>> You may find the latest version of SVNKit with GNOME Keyring support >>>>>>> at >>>>>>> https://teamcity.svnkit.com/repository/download/bt22/13537:id/deploy/org.tmatesoft.svn_1.3.5.7544.standalone.zip >>>>>>> (login as guest if prompted). >>>>>>> >>>>>>> Please notice that the corresponding code uses native binaries, so >>>>>>> JNA >>>>>>> library has to be on classpath in order to make things work. JNA >>>>>>> library >>>>>>> is included to the distribution. >>>>>>> >>>>>>> By default SVNKit doesn't try to use GNOME Keyring. To enable this >>>>>>> feature you have to set 'svnkit.library.gnome-keyring.enabled' >>>>>>> property >>>>>>> to 'true'. >>>>>>> >>>>>>> Let's consider the following use cases: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I. You use svn or jsvn utilities. >>>>>>> >>>>>>> To test SVNKit-based command line utility, jsvn, please do the >>>>>>> following: >>>>>>> >>>>>>> 1) Ensure you won't corrupt existing authentication data: >>>>>>> >>>>>>> $ copy -r ~/.subversion/auth ~/.subversion/auth.backup >>>>>>> >>>>>>> 2) Ensure you have Keyring support enabled: >>>>>>> >>>>>>> $ export SVNKIT_OPTIONS="${SVNKIT_OPTIONS} >>>>>>> -Dsvnkit.library.gnome-keyring.enabled=true" >>>>>>> >>>>>>> 3) Ensure Subversion configuration allows SVNKit to use GNOME Keyring >>>>>>> as >>>>>>> password storage: >>>>>>> >>>>>>> ~/.subversion/config file has "password-stores = gnome-keyring" line >>>>>>> or >>>>>>> corresponding line is ignored. No option means using password storage >>>>>>> available for the operating system. >>>>>>> >>>>>>> 4) Run those commands you usually use. Ensure that jsvn behaves as >>>>>>> expected and doesn't ask you to store passwords in plain text. >>>>>>> >>>>>>> $ jsvn ls $repo >>>>>>> >>>>>>> $ jsvn checkout $repo $wc >>>>>>> >>>>>>> $ jsvn commit $wc >>>>>>> >>>>>>> 5) Try to use jsvn in non-interactive mode: >>>>>>> >>>>>>> $ jsvn ls --non-interactive $repo >>>>>>> >>>>>>> $ jsvn checkout --non-interactive $repo $wc >>>>>>> >>>>>>> $ jsvn commit --non-interactive $wc >>>>>>> >>>>>>> In this mode jsvn must skip prompting you for any details. In case >>>>>>> credentials were requested by the repository and they are not yet >>>>>>> cached, jsvn has to exit with error. >>>>>>> >>>>>>> >>>>>>> >>>>>>> II. You integrate SVNKit into client-side application. >>>>>>> >>>>>>> You might already noticed some changes in classes related to >>>>>>> authentication, resp. DefaultSVNAuthenticationManager, >>>>>>> ISVNAuthenticationStorageOptions, ISVNHostOptionsProvider, etc. They >>>>>>> are >>>>>>> not public API, but could be used in certain cases. We made these >>>>>>> changes in order to support OS X Keychain and now Keyring-related >>>>>>> code >>>>>>> breaks the binary compatibility for this classes, too. >>>>>>> >>>>>>> If you're user of DefaultSVNAuthenticationManager interface there are >>>>>>> three places to look into: >>>>>>> >>>>>>> 1) ISVNAuthenticationStorageOptions interface. Its basic usage looks >>>>>>> like follows: >>>>>>> >>>>>>> ISVNAuthenticationStorageOptions authStorageOpts = new >>>>>>> ISVNAuthenticationStorageOptions() { >>>>>>> >>>>>>> // Enable or disable non-interactive mode >>>>>>> public boolean isNonInteractive() throws SVNException { >>>>>>> return false; >>>>>>> } >>>>>>> >>>>>>> // In interactive mode prompts user for credentials >>>>>>> public ISVNAuthStoreHandler getAuthStoreHandler() throws >>>>>>> SVNException >>>>>>> { >>>>>>> return null; >>>>>>> } >>>>>>> >>>>>>> public boolean isSSLPassphrasePromptSupported() { >>>>>>> return false; >>>>>>> } >>>>>>> >>>>>>> // In interactive mode asks user for the name of keyring to use >>>>>>> public ISVNGnomeKeyringPasswordProvider >>>>>>> getGnomeKeyringPasswordProvider() { >>>>>>> return null; >>>>>>> } >>>>>>> }; >>>>>>> >>>>>>> DefaultSVNAuthenticationManager manager = >>>>>>> (DefaultSVNAuthenticationManager) >>>>>>> SVNWCUtil.createDefaultAuthenticationManager(); >>>>>>> manager.setAuthenticationStorageOptions(authStorageOpts); >>>>>>> >>>>>>> As you can see there is an analogy between #isNonInteractive() method >>>>>>> and 'non-interactive' command line option. >>>>>>> >>>>>>> 2) ISVNHostOptionsProvider and ISVNHostOptions interfaces. >>>>>>> >>>>>>> One could find analogy between ~/.subversion/servers configuration >>>>>>> file >>>>>>> and ISVNHostOptions class. The last one is API for the corresponding >>>>>>> configuration options. E.g. in order to disable any authentication >>>>>>> storage, provide necessary implementation of >>>>>>> ISVNHostOptions#isAuthStorageEnabled() and make authentication >>>>>>> manager >>>>>>> use this implementation. >>>>>>> >>>>>>> 3) DefaultSVNOptions class. >>>>>>> >>>>>>> Finally, if you want to mimic ~/.subversion/config configuration >>>>>>> options >>>>>>> provide necessary instance of DefaultSVNOptions class. E.g. you can >>>>>>> restrict usage of certain password storage types via corresponding >>>>>>> implementation of DefaultSVNOptions#getPasswordStorageTypes(). >>>>>>> >>>>>>> >>>>>>> >>>>>>> III. You integrate SVNKit into server-side application. >>>>>>> >>>>>>> All the information above is also relevant for server-side >>>>>>> integration, >>>>>>> but be carefully when switching to the new version of SVNKit. Since >>>>>>> OS >>>>>>> X >>>>>>> Keychain and GNOME Keyring support is enabled, always enable >>>>>>> non-interactive mode for DefaultSVNAuthenticationManager. Otherwise >>>>>>> your >>>>>>> code most likely will get stuck during password storage access. See >>>>>>> ISVNAuthenticationStorageOptions#isNonInteractive(). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Considering these use cases, please keep in mind a known issue >>>>>>> related >>>>>>> to Keyring: >>>>>>> >>>>>>> If Keyring daemon is not running, Subversion client initializes it >>>>>>> via >>>>>>> DBus mechanism once needed. SVNKit is not able to do that. So >>>>>>> application users have to be sure, that keyring daemon is properly >>>>>>> loaded and initialized to work with. >>>>>>> >>>>>>> Thanks in advance! >>>>>>> >>>>>>> -- >>>>>>> Semen Vadishev, >>>>>>> TMate Software, >>>>>>> http://svnkit.com/ - Java [Sub]Versioning Library! >>>>>>> http://sqljet.com/ - Java SQLite Library! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> 1. It would be nice if you've had a Maven repository with nightly >>>>>> builds. >>>>>> This would have made it much easier to test this. >>>>>> >>>>>> 2. When do you expect 1.4.0 to be released? >>>>> >>>>> >> >> >>
