On Wed, Mar 20, 2013 at 11:04:31AM +0000, Philip Martin wrote: > Branko ??ibej <br...@wandisco.com> writes: > > > On 18.03.2013 16:12, phi...@tigris.org wrote: > >> http://subversion.tigris.org/issues/show_bug.cgi?id=3913 > >> > >> ------- Additional comments from phi...@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.
