[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] New Subclipse release posted

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 9 Jun 2008 12:04:22 -0400

On Mon, Jun 9, 2008 at 11:48 AM, Alexander Kitaev
<Alexander.Kitaev_at_svnkit.com> wrote:
> Hello Mark,
>> There are only two client implementations and they are both threadsafe
>> and I do not understand the username/password issue you describe.
> I have a correction on this statement - SVNKit's SVNClient implementation
> (SVNClientImpl) is not thread safe, i.e. it is expected that instance of
> SVNClientImpl is not used from different threads at the same time.
> It could be used this way when wrapped into SVNClientSynchronized though,
> but I think other issues may arise, including those with credentials.
> Regarding credentials, there is one more thing I could share about SVNKit's
> SVNClient implementation - when works within Eclipse SVNKit uses multi-layer
> credentials cache and looks for credentials in the following order:
> 0. credentials specified with username/password methods.
> 1. credentials stored in _runtime credentials cache_.
> 2. credentials stored in keyring file, i.e. persistent credentials cache.
> 3. credentials fetched from UserNamePassword prompt.
> Credentials that are accepted for certain realm are then always stored in
> runtime credentials cache, even when user decided not to save them (to avoid
> prompting credentials during the same session for each operation). By
> default runtime credentials cache is synchronized and shared between all
> SVNClientImpl instances.
> SVNClientImpl instance allows to set custom shared runtime storage with
> SVNClientImpl.setRuntimeCredentialsStorage(...) method or override this for
> certain SVNClientImpl instance with
> SVNClientImpl.setClientCredentialsStorage(...) call.
> I'm not sure whether this information is relevant to the topic (didn't yet
> read it all), but this is where SVNKit implementation differs from the
> JavaHL one.

Thanks. I have some ideas on how I can probably work around this
difference. I do have a relevant question. We never call
SVNClientInterface.dispose() and adding that in now is not going to
happen. If that method is not called and we are creating a lot of
separate objects will that cause a problem? Subclipse 1.2.x already
works that way so I assume not.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-06-09 18:04:32 CEST

This is an archived mail posted to the Subclipse Dev mailing list.