Mark Phippard wrote:
> On Tue, Jun 3, 2008 at 10:37 AM, Thomas Hallgren <thomas_at_tada.se> wrote:
> Subclipse stopped containing usernames and passwords before the 1.0
> release. The code still exists but the values would be null if using
> our UI. So the adapter under "normal" Subclipse usage does not
> contain any username or passwords, it simply contains callback
> functions that the Subversion API can choose to use if and when it
> needs to ask for credentials.
OK, I didn't know this. It would be great if you simply removed the
fields and methods or, if backward compatibility is an issue, marked the
methods as deprecated.
>> 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.
> I am not clear why it is impossible.
With the password issue out of the way and with a createSVNClient method
that creates new instances and initializes them appropriately (with
path to config in particular, since there was no public method to
obtain), I don't have an issue with this anymore.
> There are only two client implementations and they are both threadsafe
I would dispute this given the errors I get when using multi-threading
on top of the SVNKit adapater. I've specifically seen two major problems.
1. I get errors indicating that the adapter thinks that remote files are
2. I get successful reads that returns incorrect results.
How much testing has been done using concurrent threads? I'm looking at
the AbstractJhlClientAdapter, SvnKitClientAdapter, and SVNClientImpl
classes without finding any synchronized methods. To me it looks like
the implementor has intended these classes to be unsafe and that each
user must maintain his own copy. Perhaps the SVNKit team can answer that?
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 18:13:28 CEST