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-20 14:09:31 CEST