bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13513: 24.3.50; Going "--non-interactive" is the wrong thing for SVN


From: Glenn Morris
Subject: bug#13513: 24.3.50; Going "--non-interactive" is the wrong thing for SVN on OSX
Date: Wed, 23 Jan 2013 03:41:41 -0500
User-agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)

Stefan Monnier wrote:

> So, could someone explain to me when --non-interactive is needed?
> The report seemed to be for w32, does that mean that it's only ever needed
> for w32, or is it also sometimes needed under GNU/Linux?

IIUC on GNU/Linux:

Semi-recent svn default to using gnome-keyring to store encrypted
passwords for svn servers that need them. So suppose you are working in
a svn checkout of a remote repository that needs a password. You've
previously stored the password encrypted on your local disk.

Now you type any command that needs to contact the server (eg svn status
-u, or svn update). If at the command-line, you get a prompt:

  Password for 'login' GNOME keyring: 

You enter your normal user password, it decrypts the stored svn password
and everything then works.


If you call the same svn commands from Emacs VC prior to 24.1, it hangs
forever with no indication of what's going on (bug#9993). Using
--non-interactive makes it abort instantly with a meaningful error
message.

The OP says that on Mac OS X, the equivalent password prompt pops up as
a GUI dialogue box rather than a command-line prompt. Maybe there is
some way to make svn do that on GNU/Linux too, but I don't see it. (If
you go through the auth step in the shell prior to launching Emacs, then
update etc works from Emacs too without need any prompt; presumably the
decrypted svn password is cached for the rest of the session). (Note
also that bug#7152 is about needing non-interactive on Mac OS X. Maybe
it depends how you configure it?)


There is a relate issue of what happens if you manage to do an update
and it brings in conflicts. By default, this drops you into interactive
conflict resolution (bug#4280, 7152). As the OP says, this could perhaps
also be avoided using --accept=postpone rather than --non-interactive.


So in summary as far as we knew till now, all platforms needed
--non-interactive to avoid Emacs waiting forever for svn to respond,
with no indication as to what was going on.

IIUC, future svn will/may default to non-interactive in the Emacs case:
http://svn.haxx.se/dev/archive-2012-12/0432.shtml





reply via email to

[Prev in Thread] Current Thread [Next in Thread]