Sync with Subversion - "Username: Use of uninitialized value $username in chomp"

[Manuel Fegerl]

Hello.

I got a problem when trying to sync with my subversion Server. The full log:

git svn rebase
Authentication realm: <http://svn> DTI SVN
Password for 'mfegerl':
Authentication realm: <http://svn> DTI SVN
Username: Use of uninitialized value $username in chomp at /Applications/SourceTree.app/Contents/Resources/git_local/libexec/git-core/git-svn line 4035.
error: git-svn died of signal 11
Completed with errors, see above

Cannot find anything in google (except a old link that does not work anymore)

[abulka · Accepted solution]

Having worked through this issue myself, I finally got past the error. Hopefully this might help someone:

Note I am using a Mac (Mountain Lion) here. When you clone initially from e.g. google codeproject subversion repository via https, no password is required. So far so good. To use a codeproject subversion repository via Sourcetree, you must point to it using Sourcetree which then pulls the entire repo down and converts it to git format. If you want to push, sourcetree knows to use the git-svn technology to translate back into subversion format.

However for me, when I did push, sourcetree screwed up and failed, because a password is required, and somehow sourcetree doesn’t bother to prompt you for it. Same goes for the username being used - sourcetree uses your mac username rather than your codeproject username blah.

Even going into the sourcetree / repository settings / edit config (which is really .git/config) and adding

[svn]

username = blah

password = 123123123

helped a bit re username but not really re the password.

The solution for me was to straighten out my svn authentication from the terminal - totally independently of sourcetree. So I did a normal https svn checkout of the codeproject repo and did something that required a password, like doing an add/commit from the terminal. This will prompt whether to save the certificate and prompt you for username and password - all of which gets stored in ~/.subversion. You may also get a prompt (from perl?) asking to store a password in the mac keychain, which is ok.

Then go back to the other working copy created by sourcetree (the subversion to local git directory version) and pushing with sourcetree will now work.

If you want to be really clean or already have wrong subversion information (e.g. you changed your password in the repo but subversion has recorded the old one locally), you can delete the bits in ~/.subversion relating to your code repository. This is not as scary as it seems, if you

ls -R ~/.subversion

you will only see a few files, all of which are easily recreated when you answer questions from the terminal when running svn commands.

E.g.

the file in svn.simple dir is the username/password - you can delete this file e.g. 6cd...

the file in svn.ssl.server is the ssl certificate - you can delete this file e.g. f7bcb...

Incidentally you can also safely delete entries in the mac keychain app relating to your code repository - search for parts of your unique repository name and the relevant keychain entry should appear - if it exists. If you delete it, it will just get recreated as necessary.

Anyway the point it is, after clearing these areas and running a commit using svn command line (and answering the prompts) sourcetree will then operate correctly, because the command line subversion is working and authenticating ok.

[Jayraj Jog]

I have the exact same problem but my repo is hosted on https. I'm exactly at the point where Liam gave up and I really don't want to have to use SVN directly (sob)

git -c diff.mnemonicprefix=false -c core.quotepath=false svn rebase 
Authentication realm: <https://foo.com:443> Foo Subversion Repository
Password for 'jayraj': 
Authentication realm: <https://foo.com:443> Foo Subversion Repository
Password for 'jayraj': 
Authentication realm: <https://foo.com:443> Foo Subversion Repository
Password for 'jayraj': 
Authorization failed: OPTIONS of 'https://foo.com/path_to_repo/trunk/': authorization failed: Could not authenticate to server: rejected Basic challenge (https://foo.com) at /Volumes/SourceTree/SourceTree.app/Contents/Resources/git_local/libexec/git-core/git-svn line 2721

Completed with errors, see above

[stevestreeting]

This one is actually covered in the KB: http://confluence.atlassian.com/display/SOURCETREEKB/Error+Message+%27Username+Use+of+uninitialized+value+username+in+chomp%27+Due+to+System+Git

[Manuel Fegerl]

Thanks to your answer, unfortunately this happens to me with the embedded GIT as well.

[stevestreeting]

Another thing that may avoid it is including your svn username in the URL, as in https://user@host.com/path/to/repo.

[Liam Jones]

I'm also running into this problem with an SVN repo.

I've tried:

• system git vs embedded git
• username in URL vs not in URL
• keychain entry vs no keychain entry

I always get the same result:

git -c core.quotepath=false svn rebase 
Current branch master is up to date.


git -c core.quotepath=false svn dcommit 
Committing to svn://server:3693/project/trunk ...
Authentication realm: <svn://server:3693> Development Team
Password for 'liam.jones': 
Authentication realm: <svn://server:3693> Development Team
Username: Use of uninitialized value $username in chomp at /Applications/SourceTree.app/Contents/Resources/git_local/libexec/git-core/git-svn line 4410.
error: git-svn died of signal 11
Completed with errors, see above

Interestingly it's asking for a 'liam.jones' password even if I've remove the username from the URL in the config file and removed the server entry from the keychain. Not sure where it's still finding it...

I saw in another answer that I should get a prompt box/sheet to fill in the password if git is asked for one but this doesn't seem to happen. If I manually run the dcommit from the terminal (and enter the password when prompted) then it all works fine.

Any other ideas on a fix for this Steve?

[stevestreeting]

Hmm, the trouble with svn is that it does its own authentication caching too, which is probably where it's getting the username from. This usually happens if that svn URL has been used on the command line and svn has remembered the settings inside the ~/subversion/auth folder.

One thing that might fix this is to clear out the files in that directory relating to this host and run through a quick svn checkout on the console (assuming that requires a login) to prove that it works with the authentication details you're giving it. Then try it again in SourceTree.

[Liam Jones]

Thanks for the quick reply Steve.

Making some progress but it's still not working so far.

I completely destroyed my ~/.subversion directory and there are no keychain entries for this server stored.

I tried again; this switched to showing "Password for 'liam':" in the log (my local Mac account name) which is incorrect for our subversion server.

I then edited the config file and added username = liam.jones to the [svn] section which got it back to the correct account name. This has got rid of the 'use of uninitalized value $username' error but still doesn't prompt me for the password (looks like it just attempts it 3 times with a blank password and fails):

git -c core.quotepath=false svn rebase 
Current branch master is up to date.


git -c core.quotepath=false svn dcommit 
Committing to svn://server:3693/project/trunk ...
Authentication realm: <svn://server:3693> Development Team
Password for 'liam.jones': 
Authentication realm: <svn://server:3693> Development Team
Password for 'liam.jones': 
Authentication realm: <svn://server:3693> Development Team
Password for 'liam.jones': 
Authorization failed: Authentication error from server: Password incorrect at /Applications/SourceTree.app/Contents/Resources/git_local/libexec/git-core/git-svn line 4963

Completed with errors, see above

[stevestreeting]

Yeah, I hate that svn assumes user names like this. Do you have anything in your keychain at this stage for that server? That's the only way SourceTree ever supplies a password, if anything is assuming a password other than that it must be svn itself.

You might have more luck if you delete your .subversion folder again but this time, include your username in the URL. So svn://liam.jones@server for example - this should stop svn trying to assume your login name. If that doesn't work, perhaps it's specific to the svn:// protocol - I've only tested with https and ssh because I've never come across a server that was set up for svn://.

[Liam Jones]

Yeah, looks like it's probably svn protocol specific. If I place the username in the url it seems to ignore it and revert back to using my system username. Looks like that's intended behaviour though, git-svn man page says about the --username parameter:

For transports that SVN handles authentication for (http, https, and plain svn), specify the username. For other transports (eg svn+ssh://), you must include the username in the URL, eg svn+ssh://foo@svn.bar.com/project

Ah well, I can always do my svn commits from the terminal. I'll see if we can move our repo to https or svn+ssh.

Thanks again for your help Steve.

[Jayraj Jog]

Whoops. Didn't realize this was a StackOverflow style forum. All I wanted to say was that I have the same problem, but my repo is on https, so I don't even have Liam's problem

[Jayraj Jog]

Also, this issue means that any time the user's password changes (like mine did this morning), it's bye-bye Sourcetree for them. And for people like me whose organizations haven't switched to Git, and who regarded Sourcetree as their personal saviour, this is a bit of a bummer :/

[stevestreeting]

https should be fine generally, but because of svn doing it's own authentication cacheing and not flushing the prompts predictably, this can sometimes be problematic (the only reliable answer I've found is to customise svn to flush prompts better and include it in the package, but I don't want to do that because svn is not small and is only really for legacy support). Two things that might help:

1. Open Keychain Access, search for the svn server in question and change the password there. svn itself creates this entry if you have a recent version
2. If that doesn't work, drop to the command line briefly and just issue 'svn info your_URL'. Entering the new password there will put it in svn's cache

[Jayraj Jog]

YES! Using svn info to change my password works! Thanks!!

PS. I had already previously tried to change my Keychain Access info for the URL item before posting here. That didn't work.