[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: Tue, 3 Jun 2008 10:03:57 -0400

On Tue, Jun 3, 2008 at 9:35 AM, Thomas Hallgren <thomas_at_tada.se> wrote:
> Mark Phippard wrote:
>>
>> All of the behavior you describe is intentional and took a fair amount
>> of work to get to its present state. I am not really sure what we
>> would change.
>>
>
> I can think of two minor additions to the API that would help a lot:
>
> 1. A new method: SVNClientManager.createSVNClient(boolean noCache). The
> argument would ensure that a new instance is created and that it is not
> cached.
> 2. A ISVNRepositoryLocation.setCredentials(ISVNClientAdapter client) that
> would assign the username/password to the client.
>
> By passing the 'noCache' flag to the createSVNClient method, the developer
> assumes the responsibility to call dispose() once he's done with the
> adapter.

We could likely add the first, but I cannot see adding the second. An
ISVNRepositoryLocation should not have any knowledge of your
credentials. Other than ones that were created pre-1.0 release before
we removed them.

>> Now that we have made SVNClientAdapter it's own plugin have you
>> considered targeting it directly?
>>
>
> The primary reason for our integration with Subclipse is to integrate with
> the repository management and other preferences that Subclipse maintains
> (config directory, choice of client implementation etc.).
>
> I'm curious as to why you decided to do this regression. The client adapter
> is stateful and making making it a singleton essentially forces all accesses
> to all repositories to be serialized. This has a negative performance within
> Subclipse as well. Try expadning some folders simultaneously in the SVN
> repository view for instance. It's a lot faster in 1.2.4. Everything seems
> to be built to provide stable multi-threaded access to the SVN repositories
> but this change effectively impedes anyone from using it that way.

We have not explicitly set out to serialize access to the adapter.
Can you pinpoint the specific area where you feel we have done this?

We made this change to potentially boost performance slightly, by not
constantly constructing new adapters, and more importantly because we
were not using the JavaHL API properly in that we were never calling
the dispose() method. Doing so would essentially be impossible to add
and get tight. JavaHL itself is threadsafe and it seemed like a lot
better way to work with it.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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-03 16:04:09 CEST

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