On Wed, Mar 20, 2013 at 11:04:31AM +0000, Philip Martin wrote:
> Branko ??ibej <brane_at_wandisco.com> writes:
>
> > On 18.03.2013 16:12, philip_at_tigris.org wrote:
> >> http://subversion.tigris.org/issues/show_bug.cgi?id=3913
> >>
> >> ------- Additional comments from philip_at_tigris.org Mon Mar 18 08:12:42 -0700 2013 -------
> >> The current behaviour is a deliberate design, see the log for r1424037. The
> >> clients automatically switch to non-interactive when stdin is not a terminal as
> >> that prevents scripts hanging in some circumstances and --force-interactive was
> >> introduced to allow the user to override that decision.
> >
> > Given that there are several cases where this decision (to assume
> > --non-interactive if stdin is not a terminal) may lead to somewhat
> > unexpected behaviour, I propose the following:
> >
> > * Leave the --non-interactive assumption as it now stands. One could
> > argue that, e.g., "svnrdump load" or "svnadmin load", which behave
>
> Only svnrdump is affected, svnadmin doesn't prompt.
>
> > like stream filters, should behave differently -- however, the
> > purpose of the assume-non-interactive change was to avoid the cases
> > where automated scripts would unexpectedly hang waiting for input
> > (possibly, in the case of post-commit scripts, resulting in a minor
> > DoS) instead of returning an error when, e.g., required credentials
> > are not available. It is, in my opinion, much better overall to be
> > consistent.
> >
> > * To mitigate the circumstance that users will now more often have to
> > type --force-interactive on the command line, I propose we allocate
> > one of our carefully-hoarded single-letter options for this
> > behaviour. I propose -i, which aligns with similar options of
> > standard unix tools, e.g., rm, cp, mv, expect, etc. Neither -i nor
> > -I (an alternative, though less desirable spelling) are currently
> > used by the command-line client.
>
> The sort of cases where the user will have to type --force-interactive
> are:
>
> svn commit -F -
> svn propset --revprop -rN -F -
> svn commit --targets -
> svnmucc put -
>
> Those look like commands that would be used in scripts rather than
> interactively, I think it will be rare for the user to type one of those
> and then have to type the long option --force-interactive. That leaves
> "svnrdump load" as the single place a user will type the short option.
'svnrdump load' is actually an admin command, users shouldn't use it normally.
(For starters, because it expects a dumpfile input, and the client doesn't know
what dumpfiles are.) Also, it might be blocked altogether: svn.apache.org
is configured to reject 'svnrdump load' attempts.
IOW, 'svnrdump load' is not a good argument in favour of a short option.
> I can see "svnrdump load" being used from the command line but not
> repeatedly the way one uses "svn commit". I'm not convinced a short
> option is necessary.
Received on 2013-03-20 18:49:49 CET