If the file with the cached credentials (the file under <subversion
config dir>/auth/svn.simple) is read-only, 'svn' 1.8 (on Windows) will
behave as follows after a password change:
[[[
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 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
--
Johan
Received on 2014-05-17 03:43:05 CEST