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