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 trobin...@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 trobin...@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: trobin...@systemsbiology.org > Password for 'trobin...@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 > trobin...@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
