[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1658123 - in /subversion/trunk/subversion: bindings/javahl/native/OperationContext.cpp bindings/javahl/native/Prompter.cpp bindings/javahl/native/Prompter.h libsvn_auth_gnome_keyring/gnome_keyring.c

From: Branko Čibej <brane_at_wandisco.com>
Date: Sun, 08 Feb 2015 12:04:36 +0100

On 08.02.2015 10:58, Bert Huijben wrote:
>> -----Original Message-----
>> From: Mark Phippard [mailto:markphip_at_gmail.com]
>> Sent: zondag 8 februari 2015 02:48
>> To: dev_at_subversion.apache.org
>> Cc: commits_at_subversion.apache.org
>> Subject: Re: svn commit: r1658123 - in /subversion/trunk/subversion:
>> bindings/javahl/native/OperationContext.cpp
>> bindings/javahl/native/Prompter.cpp bindings/javahl/native/Prompter.h
>> libsvn_auth_gnome_keyring/gnome_keyring.c
>>
>> What might this be useful for? Non-GUI apps? I assume this will not break
> the
>> current functionality, which finally works as of 1.8.11.
> It will only change behavior if the prompt function is both hooked *and*
> does provide a password. Some optional callback that allows to provide a
> password should be added to JavaHL, as using JavaHL doesn't imply that you
> are using a GUI that has access to the Gnome display handling.

I don't like the idea of exposing platform-specific authentication
callbacks in the JavaHL API.

IIUC, if you're using the command-line client in a headless terminal and
want to use the Gnome keyring, you have to start the Gnome keyring
daemon and unlock the keyring manually, e.g., as described here:

http://superuser.com/questions/141036/use-of-gnome-keyring-daemon-without-x

I don't see a good reason to have JavaHL behave differently.

-- Brane
Received on 2015-02-08 12:06:44 CET

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