On Fri, May 16, 2014 at 2:47 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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).
>
Not much interest it seems. Filed an issue, so this doesn't get forgotten:
http://subversion.tigris.org/issues/show_bug.cgi?id=4504
I don't have the time nor expertise right now to work on this, but if
someone else wants to have a go ... by all means.
Keep in mind that a lot of users coming from SVNKit to svn will see
this as a performance issue in 'svn'. Not really a good first
impression when they switch to the "native side".
--
Johan
Received on 2014-05-21 00:36:58 CEST