2008-05-29 17:23:03 Philip Martin napisał(a):
> Arfrever Frehtes Taifersar Arahesis <arfrever.fta_at_gmail.com> writes:
>
> > 2008-05-29 15:42:25 Mark Phippard napisał(a):
> >> On Thu, May 29, 2008 at 9:34 AM, Philip Martin <philip_at_codematters.co.uk> wrote:
> >> >
> >> > The code still drops the error. Why is this code different from the
> >> > RA loader code? Why don't you simply return the error?
> >>
> >> Is it because we expect the error to happen and we want to just know
> >> there was an error and fallback to the other mechanisms? For example
> >> if SVN is built with gnome-keyring and you are using the command line
> >> in a terminal where those libraries are not available?
> >
> > Rather when Subversion is built with support for GNOME Keyring, but
> > GNOME Keyring isn't installed.
>
> That doesn't explain the current code. After svn_dso_load has
> returned SVN_NO_ERROR you check dso to see if the library loaded;
> that's the normal path and the library may or may not get loaded. The
> exceptional path is that svn_dso_load returns an error, that's not
> normal and the error should not be thrown away.
Can the "Can't grab DSO mutex" or "Can't ungrab DSO mutex" error cause
any problems when this error is ignored?
> One final point, why is code duplicated in libsvn_subr and javahl?
We don't want to create a new public function only to load authentication
providers. JavaHL duplicates many other parts of code.
--
Arfrever Frehtes Taifersar Arahesis
Received on 2008-05-29 18:27:26 CEST