Daniel:
As mentioned in my original mail, this is indeed a cache invalidation
problem reliant on the contents of ~/.subversion/auth, which is
trivially worked around by removing the contents thereof. The problem
I'm trying to raise is a lack of parity with the behavior of plain SVN,
which also handles the server challenge on commit poorly but in a less
obtrusive way. That is, in their case, --username takes precedence over
the contents of the cache.
In both cases, the lack of a descriptive error message is more
problematic than the lack of an automated fix for the problem. I have of
course raised the issue with SVN as well, such that if they add this
message, Git will also handle this issue more gracefully when the
changes are integrated through Perl SVN.
Thank you for your response,
- Tom Robinson
On 8/20/11 5:08 AM, Daniel Shahaf wrote:
> Passing --username at checkout time is a no-op for HTTP-served
> repositories that allow anonymous read access.
>
> Seems that you have your username/password cached on the first box but
> not on the second box?
>
> In any case: rm -rf ~/.subversion/auth/svn.simple/ will remove the
> locally-cached usernames/passwords. (Note for the archives: it won't
> remove details associated with client certificates.) Or, alternatively,
> pass --username to the 'svn commit' command too.
>
> Does this address your issue?
>
>
>
> Thomas Robinson wrote on Fri, Aug 19, 2011 at 14:06:40 -0700:
>> The following is a bug report for triage and review. I've been
>> unable to locate an adequate fix or discussion for this issue;
>> however, I have found an acceptable workaround.
>>
>>
>> When built on OSX, SVN versions 1.6.16 (r1073529) and 1.6.17
>> (r1128011) appear to handle authentication challenges on commit in a
>> non-robust manner.
>>
>> The testing that follows is against a Google Code project that I
>> currently maintain code for, which may be found here:
>> http://code.google.com/p/rf-ace/
>>
>>
>> Here is a sparse log of a fresh checkout and commit using SVN
>> version 1.6.16 (r1073529) on OSX. All builds are inclusive of
>> ra-neon:
>>
>> $ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace.svn
>> --username trobinson_at_systemsbiology.org
>> ... file data ...
>> Checked out revision 265.
>>
>> $ cd rf-ace.svn
>> ... make some changes to existing files ...
>>
>> $ svn commit
>> ... write the log in my default editor ...
>>
>> "svn-commit.tmp" 35L, 1392C written
>> svn: Commit failed (details follow):
>> svn: access to '/svn/!svn/act/c23cbe26-fda3-46d6-a358-d1d20738c4bf'
>> forbidden
>> svn: Your commit message was left in a temporary file:
>> svn: '/path/to/my/repo/scrubbed/from/this/report/rf-ace.svn/svn-commit.tmp'
>>
>> This same behavior exhibits in 1.6.17 (r1128011), and when a log
>> message is given using -m.
>>
>>
>>
>> Here is an approximately equivalent session using SVN version 1.6.11
>> (r934486) in CentOS 6:
>>
>> $ svn checkout https://rf-ace.googlecode.com/svn/trunk/ rf-ace
>> --username trobinson_at_systemsbiology.org
>> ... file data ...
>> Checked out revision 265.
>>
>> $ cd rf-ace
>> ... make some changes to existing files ...
>>
>> $ svn up
>> ... file data ...
>> Checked out revision 269.
>>
>> $ svn commit -m "Irrelevant log message you can find in r270 of rf-ace"
>> Authentication realm:<https://rf-ace.googlecode.com:443> Google
>> Code Subversion Repository
>> Password for 'trobinso':
>> [In which I press enter here to fall back to explicit Username
>> specification]
>>
>> Authentication realm:<https://rf-ace.googlecode.com:443> Google
>> Code Subversion Repository
>> Username: trobinson_at_systemsbiology.org
>> Password for 'trobinson_at_systemsbiology.org': [My correct password is
>> entered here]
>> Sending test/argparse_test.hpp
>> Transmitting file data .
>> -----------------------------------------------------------------------
>> ATTENTION! Your password for authentication realm:
>>
>> <https://rf-ace.googlecode.com:443> Google Code Subversion Repository
>>
>> 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
>> '/my/home/directory/.subversion/servers'.
>> -----------------------------------------------------------------------
>> Store password unencrypted (yes/no)? yes [I know, I know. See my
>> notes below.]
>>
>> Committed revision 270.
>>
>>
>> Note that on personal dev boxes, authentication information has been
>> stored locally in ~/.subversion (which, I note as an aside, is
>> something I only do with definedly-insecure passwords like those
>> automatically generated by Google Code on machines that are for
>> internal development only). This, too, may cause the issue.
>>
>> My workaround, of course, is obvious. For all versions of SVN,
>> specifying the username explicitly (a la "--username
>> trobinson_at_systemsbiology.org") immediately follows up with a
>> challenge for my password. I have not verified if this resolves
>> future commit attempts.
>>
>>
>> The catalyst for the issue is Google's recent transition of Google
>> Code login system to that of Google Accounts. In this case, for
>> conflicting users, the issue only exposed itself when we cut back
>> over to our original usernames, and I would speculate this occurs if
>> (and only if)
>> the same username is specified with an alternate password (as mine was).
>>
>> Thus, we have a compelling case for potentially spurious handling of
>> conflicting user credentials, as may well expose themselves in the
>> migration of Google Code SVN repositories. In which I would
>> speculate that the right approach would be to invalidate the cached
>> copy of the user's credentials and re-challenge both the username
>> and the password. Ideally, this behavior would be grafted into a
>> configuration value, should it not already exist.
>>
>>
>> As you might expect, searching for this information is
>> nigh-impossible for this exact edge condition, and you will probably
>> receive several queries of a similar nature as Google continues to
>> transition accounts with access to Google Code. Thus my posting of
>> this bug report: assuming my hypothesis is correct, it's a case of
>> inconsistent credential handling that results in a non-intuitive
>> error message. As above, this would be better handled by
>> configurable invalidation of the user's cached credentials.
>>
>> Thus concludes my report. Please copy me on any mail you expect for
>> me to see, as I am not a subscriber to this list.
>>
>>
>> Best regards,
>> - Tom Robinson
Received on 2011-08-22 20:46:03 CEST