[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 13:36:33 -0400

On Tue, Jun 3, 2008 at 12:13 PM, Thomas Hallgren <thomas_at_tada.se> wrote:
> 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.

I will look into it. In the run-up to 1.0 we realized that we could
provide a better user experience by allowing Subversion to manage the
credentials and instead properly implement all of the callbacks it
uses. We left the code in place for existing users with existing
connections that contained this data. But the UI has not allowed you
to create a new connection with credentials in it since 0.9.100.

>> 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
> directories.
> 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?

We code and test to JavaHL and rely on SVNKit to maintain
compatibility with JavaHL. We do not code to SVNKit specifically, we
code to the JavaHL interface. I'd have to search the mailing list but
when we made this change I recall exchanging emails about it with the
SVNKit team.

-- 
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 19:36:44 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.