Major See also http://svn.haxx.se/dev/archive-2014-05/0102.shtml. If the file with the cached credentials (the file under <subversion config dir>/auth/svn.simple) is read-only, 'svn' 1.8 (on Windows) works extremely slowly (and fails to update the credentials cache), and it gives a bogus "can only be stored unencrypted" prompt. [[[ C:\>svn ls https://svn.example.com/svn Authentication realm: <https://svn.example.com:443> SVN Password for 'myself': ******** ### delay of 10+ seconds ----------------------------------------------------------------------- ATTENTION! Your password for authentication realm: <https://svn.example.com: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 'C:/Some/Path/Subversion/servers'. ----------------------------------------------------------------------- Store password unencrypted (yes/no)? yes ### another delay of 10+ seconds branches/ tags/ trunk/ ]]] Some observations: - The "can only be stored unencrypted" prompt is completely bogus. It can't and it won't. After the above operation, the new password is not stored. The next svn invocation will again prompt for the password. BTW, with svn 1.7 the "can only be stored unencrypted" prompt does not appear, so this is new-in-1.8 behavior. - The two 10+ seconds delays: this is some kind of retry-loop. Looking with ProcMon, I observed that during this delay svn.exe performs exactly 101 attempts to write to the auth-cache file (which all fail with ACCESS DENIED). Shouldn't svn be able to write to the file anyway, even if it's read-only, because I'm the owner? If not, a failure with a clear error message would be better than the current behavior. Now, the reason why this file happens to be read-only is because of SVNKit. Apparently, SVNKit makes the file read-only when it caches credentials. I have reported an issue in their issue tracker for this [1], but in any case I think native svn should be able to handle this better (users that switch between different clients, or which are migrating from SVNKit to svn, can easily run into this). P.S.: I don't know if the same problem is present on other platforms ... I only tested this on Windows. [1] http://issues.tmatesoft.com/issue/SVNKIT-508 -- SVNKit sets auth cache file (svn.simple) read-only, causing problems for native svn