Subversion 1.8 "--non-interactive" and "--force-interactive" flags behavior

[Konstantin Kolosovsky]

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?

Many thanks,
Konstantin

--
Konstantin Kolosovsky
Software Developer
JetBrains
http://www.jetbrains.com
"Develop with pleasure!"

[Branko Čibej]

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
--password.

The better option of course is to just use the JavaHL API instead.

-- Brane


--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

[Mark Phippard]

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.

Personally, I think this is a regression and not an improvement.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

[Branko Čibej]

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@. :)

[Mark Phippard]

On Mon, Aug 5, 2013 at 10:20 AM, Branko Čibej <br...@wandisco.com> wrote:

>>> 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@. :)

When the changes were made I just assumed Java apps would still work.
I assumed the code would just see the JVM as being the terminal. I
also generally trust the dev team to not introduce regressions. Guess
I was wrong on both counts.