On Mar 3, 2011, at 4:24 PM, Johan Corveleyn wrote: > On Thu, Mar 3, 2011 at 6:25 PM, Rudy Grigar <r...@tag1consulting.com> wrote: >> I worked through an issue this morning with a Subversion user that was >> unable to store a password locally: >> >> Authentication realm: <https://code:443> Zinch SVN Drupal >> Password for 'dev': >> >> ----------------------------------------------------------------------- >> ATTENTION! Your password for authentication realm: >> >> <https://code:443> SVN >> >> can only be stored to disk unencrypted! You are advised to configure >> your system so that Subversion can store passwords encrypted, if >> possible. See the documentation for details. >> >> You can avoid future appearances of this warning by setting the value >> of the 'store-plaintext-passwords' option to either 'yes' or 'no' in >> '/var/lib/hudson/.subversion/servers'. >> ----------------------------------------------------------------------- >> Store password unencrypted (yes/no)? yes >> At revision 2260. >> [hudson@srv-zinch-ec2db3 devdrup.zinch.com]$ svn up >> Authentication realm: <https://code:443> Zinch SVN Drupal >> Password for 'dev': >> >> ----------------------------------------------------------------------- >> ATTENTION! Your password for authentication realm: >> >> <https://code:443> SVN >> >> can only be stored to disk unencrypted! You are advised to configure >> your system so that Subversion can store passwords encrypted, if >> possible. See the documentation for details. >> >> You can avoid future appearances of this warning by setting the value >> of the 'store-plaintext-passwords' option to either 'yes' or 'no' in >> '/var/lib/hudson/.subversion/servers'. >> ----------------------------------------------------------------------- >> Store password unencrypted (yes/no)? yes >> At revision 2260. >> >> >> The password wasn't actually being stored, the root of the problem being >> that auth/svn.simple/* was set read-only/444 (the cause of this is still >> unknown). >> >> I talked to Stefan (stsp) this morning in #svn and he wants to add better >> error handling here when the file isn't writable instead of silently failing >> to store the password. The relevant IRC log is here: >> http://colabti.org/irclogger/irclogger_log/svn?date=2011-03-03#l243 >> > > I've seen this happen recently by using svnkit ([1]). I don't remember > the exact conditions (I was experimenting with use of svnkit via > svnant in an ant build script), but it happened only when using a > recent version of svnkit (1.3.5, i.e. the latest version at this time; > with svnkit 1.2.0 the problem didn't happen). > > Is svnkit possibly involved somehow? > > I think svnkit does this when running on unix with the "unencrypted" > situation. It's trying to cache the password, but it won't do it > because it's going to be stored unencrypted. After that, the file > seems to be read-only. > > -- > Johan > > [1] http://www.svnkit.com/
svnkit isn't being used currently. Hudson is being used to auto update the dev environment, but it's just using a standard 'svn up' from the shell. It's also possible that someone else reconfigured or changed this around without me knowing -- the box that this is configured on is a bit of a moving target. I'm more interested in seeing an improved error message when the permissions prevent the password from being stored. Thanks! Rudy
