Mark Phippard wrote:
> 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.
>
>
What I meant when I wrote 'credentials' was 'username & password'. This
is what I'd envision would be in that method:
public void setCredentials(ISVNClientAdapter svnClient) {
svnClient.setUsername(getUsername());
String password = getPassword();
if (password != null)
svnClient.setPassword(password);
}
The method could of course be named 'setUserNameAndPassword'.
Essentially this what I want to work around:
/**
* get the svn client corresponding to the repository
* @throws SVNException
*/
public ISVNClientAdapter getSVNClient() throws SVNException {
ISVNClientAdapter svnClient =
SVNProviderPlugin.getPlugin().createSVNClient();
svnClient.addNotifyListener(NotificationListener.getInstance());
svnClient.setUsername(getUsername());
String password = getPassword();
if (password != null)
svnClient.setPassword(password);
return svnClient;
}
Given the proposed method, I could instead do:
ISVNClientAdapter client = plugin.createSVNClient(true);
myRepository.setCredentials(client);
> 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?
>
>
The adapter is stateful (holds username/password info) and it isn't
always synchronized. So in order to do something in parallel, you'll
need more then one instance. The way it used to work, I could create new
instances as I went along and dispose them when I was done. Not so now.
There's only one instance and it delivers incorrect content, considers
my files to be directories, or logs in using incorrect username/password
if I try to use it from multiple threads.
Specifically, it is impossible to perform paralell task on an
ISVNClientAdapter delivered by the SVNClientManager.createSVNClient()
or the ISVNRepositoryLocation.getSVNClient() method. I'm confined to
use those methods since there's no other way of getting a client adapter
properly initialized according to the preferences, usernames, and
passwords that Subclipse maintains through preferences and repository
locations.
> 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.
>
The fact that JavaHL is capable of multi-threading is of little
importance to me. I want to provide a stable implementation on top
regardless of client implementation. The choice is up to the user. But
even if all client implementations were multi-thread safe, you still
assign username/password to the client instance. So thread-safe or not,
it cannot be used from multiple threads unless those threads are using
the same username/password.
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 16:37:12 CEST