On Thu, May 15, 2014 at 4:16 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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
>
I'd like to add that, if there is any interest in helping users
migrate from SVNKit to svn (like we are doing in our company now that
IntelliJ IDEA finally has support for integrating with a commandline
svn client), it would be good to fix this.
Indeed, all users that have used SVNKit in the past, and then use a
native client, will most likely run into this. With much head
scratching and amazement at how extremely slow native svn is (wow, 30
seconds just for executing 'svn ls', that's ... amazing).
--
Johan
Received on 2014-05-16 17:22:03 CEST