On 05.08.2013 16:12, Mark Phippard wrote:
> On Mon, Aug 5, 2013 at 10:03 AM, Branko Čibej <brane_at_wandisco.com> wrote:
>> On 05.08.2013 12:14, Konstantin Kolosovsky wrote:
>>> Hi Everyone,
>>> I've got a question about "--non-interactive" and
>>> "--force-interactive" flags behavior in Subversion 1.8.
>>> I'm not subscribed to the mailing list, please put my email in Cc in
>>> any responses.
>>> We've got java application interacting with svn.exe command line
>>> utility. For Subversion 1.7 our authentication behavior was the following:
>>> - executing command using svn.exe, for instance "svn udpate"
>>> - getting "authentication realm" from process output
>>> - destroying process
>>> - creating correct credential cache for the obtained "authentication
>>> realm" (for instance, correct file with encrypted password in the
>>> "auth" folder for Windows)
>>> - executing command using svn.exe once again - so that authentication
>>> goes smoothly as necessary information is in credential cache
>>> With Subversion 1.8 client we can not get "authentication realm" to
>>> create correct credential cache information:
>>> - if not specifying "--force-interactive" flag or specifying
>>> "--non-interactive" flag - process output contains authentication
>>> failure message, but only with repository url - not the
>>> "authentication realm"
>>> - if specifying "--force-interactive" flag - process "hangs" not
>>> providing any output - so there is no way to get "authentication
>>> realm" from it and then destroy the process
>>> So the question is - is it possible to somehow return previous
>>> behavior of svn.exe client - so that it does not "hang" but just
>>> "waiting" for the "user input" providing necessary "authentication
>>> realm" in the output?
>>> Or what would you recommend in such situation when authentication is
>>> necessary when interacting with svn.exe utility from java application?
>>> Is directly specifying "--username" and "--password" keys the only
>>> available option?
>> If you use --force-interactive, you're telling Subversion to prompt the
>> terminal, if any -- as of 1.8, prompting on stdin/stderr is only the
>> last resort. So for scripting the command-line client the way you're
>> doing, I'd recommend to pass --non-interactive and --username and
>> The better option of course is to just use the JavaHL API instead.
> I have seen this problem as well. We have a Java server application
> that scripts the command line so that it can retrieve and accept the
> SSL certificate. We added the new --force-interactive option but the
> problem is that the prompting seems to happen in the process that
> started the Java server application instead of in the application
> itself. So it is no longer possible to capture the command line output
> with the certificate details and accept it.
It has nothing to do with processes. We prompt the terminal, and read
responses from the terminal, instead of using stderr for the prompt and
stdin for the response. Note that on Windows, this was always the case
for certain kinds of prompts. 1.8 merely makes that consistent.
> Personally, I think this is a regression and not an improvement.
You had a year and a half to raise this on dev@. :)
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
Received on 2013-08-05 16:21:05 CEST