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.
> 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.
Regards,
Thomas Hallgren
---------------------------------------------------------------------
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 15:36:02 CEST