Stefan Sperling <[email protected]> writes:
> On Wed, Feb 08, 2012 at 07:01:48PM +0200, Daniel Shahaf wrote:
>> So, you are saying that there is no legitimate/supported scenario in
>> which the .py and .so are out of sync with each other? And that code
>> written for a library version that has the symbol will return a normal
>> error (eg, AttributeError in Python) when run against a library version
>> (such as 1.7.2) that doesn't have the symbol?
>>
>> (I'm talking about the .so here; it's not clear to me whether your
>> reference to hasattr() checked the existence of the symbol in the .py
>> library file or in the .so library file.)
>>
>> In these cases it seems to me that we might be able to backport this.
>> Stefan?
>
> I have no idea :)
I think the problem is that in Python one has to write:
if hasattr(core, 'svn_auth_set_gnome_keyring_unlock_prompt_func'):
core.svn_auth_set_gnome_keyring_unlock_prompt_func(ctx.auth_baton,
prompt_func_gnome_keyring_prompt)
If called unconditionally:
core.svn_auth_set_gnome_keyring_unlock_prompt_func(ctx.auth_baton,
prompt_func_gnome_keyring_prompt)
it will work with 1.7.3 and fail with 1.7.2. In Ruby the magic is:
if Svn::Ext::Core.respond_to?(:svn_auth_set_gnome_keyring_unlock_prompt_func)
Svn::Ext::Core::svn_auth_set_gnome_keyring_unlock_prompt_func(ctx.auth_baton,
gnome_keyring_prompt)
and I suppose Perl might have something similar.
I think that means this is not suitable for a backport.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
