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-tp31183957p31571357.html Sent from the SVNKit - Users mailing list archive at Nabble.com.
