Ok, I'll implement such a provider and make it work. Thanks for your time and your great product!
/Jakob Semyon Vadishev wrote: > > Hi, > >> I've managed to build the 1.3.6-SNAPSHOT from >> http://svn.svnkit.com/repos/svnkit/branches/1.3.x (Hopefully this is >> correct?) > Yes, that's correct version to use. We've restarted our Maven > repository. If this repository was the reason of the failure yesterday, > it must be fixed now. > >> But I still get this error on my Linux test server. Might be something >> I'm >> doing wrong though? > I had a look into your code, and it seems repository access always > relies on cached credentials, which generally is not acceptable for > tools like yours. I'd implement some proper authentication provider just > like this one we have already implemented for our command line interface — > > https://svn.svnkit.com/repos/svnkit/branches/1.3.x/svnkit-cli/src/main/java/org/tmatesoft/svn/cli/SVNConsoleAuthenticationProvider.java > > Find usages of the class, they are quite straightforward. All it does — > asks user for login, password, client certificate file, passphrase, etc. > If caching is supported in corresponding environment, credentials cached > automatically once user successfully authenticated. > > Regarding password storages: > > - Currently caching works fine on Windows and OS X (both 10.5.x and > 10.6.x). > > - On Linux with GNOME you have to set certain system variable to make > it work — I've described that in my initial email of this thread. > > - On Linux with KDE SVNKit is not able to securely save passwords, > though Subversion does support that. > > - With other operating systems and desktop environments both > Subversion and SVNKit can save passwords in plain text only, i.e. not > securely. > > I'm afraid on your Linux server SVNKit failed to find necessary GNOME > libraries to work with keyring. As result it could not read password > from the cache and could not authenticate when repository requested > credentials. > > Semen Vadishev, > TMate Software, > http://svnkit.com/ - Java [Sub]Versioning Library! > http://sqljet.com/ - Java SQLite Library! > > > On May 31, 2011 16:37 , lazee wrote: >> I've managed to build the 1.3.6-SNAPSHOT from >> http://svn.svnkit.com/repos/svnkit/branches/1.3.x (Hopefully this is >> correct?) >> >> But I still get this error on my Linux test server. Might be something >> I'm >> doing wrong though? >> >> The source code is available here : https://github.com/lazee/JRBC >> >> Error: >> >> svn: Authentication required for '<http://foo.local:80> SVN' >> SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: >> Authentication required for '<http://svn.foo.no:80> SVN' >> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >> required for '<http://svn.foo.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.getFirstAuthentication(DefaultSVNAuthenticationManager.java:182) >> at >> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:563) >> 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.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482) >> at >> org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:876) >> at >> org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534) >> at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2571) >> at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2494) >> at >> net.jakobnielsen.jrbc.svn.SvnSupport.getRepositoryInfo(SvnSupport.java:119) >> >> >> >> >> >> >> Semyon Vadishev wrote: >>> Hello Jakob, >>> >>> 1.3.x snapshots are already available in our maven repository. Can you >>> please test this version of SVNKit? >>> >>> Thanks in advance. >>> >>> Semen Vadishev, >>> TMate Software, >>> http://svnkit.com/ - Java [Sub]Versioning Library! >>> http://sqljet.com/ - Java SQLite Library! >>> >>> >>> On May 8, 2011 20: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? >>>>>>>> >>>>> >>>>> >>> >>> > > > -- View this message in context: http://old.nabble.com/GNOME-Keyring-support-tp31183957p31763821.html Sent from the SVNKit - Users mailing list archive at Nabble.com.
