JonnyJD
JonnyJD

Reputation: 2643

"git svn" commands fail with "Value is not a string (or undef) at /usr/share/perl5/vendor_perl/Git/SVN/Ra.pm line 96"

I have a git repository created with git svn clone from an upstream SVN repository. The repository was created and configured some time ago (1 or 2 years). Pulling (git svn fetch/git svn rebase) and pushing (git svn dcommit) worked fine before. I stopped using the repository for a couple of months and using any of these commands now fails with:

Value is not a string (or undef) at /usr/share/perl5/vendor_perl/Git/SVN/Ra.pm line 96

So I am not able to use git-svn. How can I make it work again?

I am running Arch Linux so there is a good chance there was an update to either Subversion or Git that somehow broke my setup. However, I didn't find anything related when searching for the error message. The perl line in question looks like this in my current git version (since line 96 might be different in other versions):

SVN::_Core::svn_auth_set_parameter($baton,
    $SVN::_Core::SVN_AUTH_PARAM_DONT_STORE_PASSWORDS,
    bless (\$dont_store_passwords, "_p_void"));

I am currently using subversion 1.9.2 and git 2.6.1

EDIT: The same problem is tracked in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797705

Upvotes: 0

Views: 364

Answers (2)

VonC
VonC

Reputation: 1327364

Git 2.7.1 should soon (February 2016) fix this issue.

See commit 0b66415 (16 Jan 2016) by Eric Wong (ele828).
(Merged by Junio C Hamano -- gitster -- in commit 6d579a0, 01 Feb 2016)

git-svn: fix auth parameter handling on SVN 1.9.0+

For users with "store-passwords = no" set in the "[auth]" section of their ~/.subversion/config, SVN 1.9.0+ would fail with the following message when attempting to call svn_auth_set_parameter:

Value is not a string (or undef) at Git/SVN/Ra.pm

Ironically, this breakage was caused by r1553823 in subversion:

"Make svn_auth_set_parameter() usable from Perl bindings."

Since 2007 (602015e), git-svn has used a workaround to make svn_auth_set_parameter usable internally.
However this workaround breaks under SVN 1.9+, which deals properly with the type mapping and fails to recognize our workaround.

For pre-1.9.0 SVN, we continue to use the existing workaround for the lack of proper type mapping in the bindings.

Tested under subversion 1.6.17 and 1.9.3.

I've also verified r1553823 was not backported to SVN 1.8.x:

BRANCH=http://svn.apache.org/repos/asf/subversion/branches/1.8.x
svn log -v $BRANCH/subversion/bindings/swig/core.i

ref: https://bugs.debian.org/797705

Upvotes: 1

JonnyJD
JonnyJD

Reputation: 2643

I am still not sure what piece of software needs to change (if any), but with the perl code I could pinpoint the problem to my configuration.

To keep subversion from storing passwords I had in ~/.subversion/config:

[auth]
store-passwords = no

Commenting the line (# store-passwords = no) made git svn work again. Starting with subversion 1.6 specifying this setting in the file config was deprecated (but worked). However, subversion 1.9.x (probably starting with 1.9) seems to remove this option altogether (I couldn't find the 1.9 Documentation, http://svnbook.red-bean.com still features 1.8 as "nightly"). This didn't break subversion, but it did break git svn for me.

Starting with Subversion 1.6 this option can be given in ~/.subversion/servers instead:

[global]
store-passwords = no

This might be a bug in the subversion perl files that is triggered by git-svn. However, I am not fluent enough in perl to make a good bug report about that. Additionally, my configuration is wrong (for subversion 1.9) and I wouldn't have found out about that if it didn't break in some way. Might be good to break in a "better" way though.

EDIT: There is now a patch for git-svn available at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797705;msg=15

Upvotes: 0

Related Questions