[RFH] - git-svn auth bug (possibly SVN 1.5.0-related)

Brad King [off-list ref] wrote:

Eric Wong wrote:

quoted

Brad King [off-list ref] wrote:

quoted

Eric Wong wrote:

quoted

I haven't had the chance to look at this.   Can anybody else shed more
light on that bug?  It's really strange that the tests won't run because
of it.  Are you unable to run some git-svn tests or all of them?

Just that one fails.  All others (including the one in the patch below) pass.

Exactly which test fails for you?  Perhaps it's some setting in your
~/.subversion/config that's causing it to fail.  Maybe we should set
$HOME and use a clean ~/.subversion/config for git-svn tests regardless
if that turns out to be the case...

$ cd $gitsrc/t
$ export SVNSERVE_PORT=5432
$ ./t9113-git-svn-dcommit-new-file.sh
*   ok 1: start tracking an empty repo
* FAIL 2: create files in new directory with dcommit

                mkdir git-new-dir &&
                echo hello > git-new-dir/world &&
                git update-index --add git-new-dir/world &&
                git commit -m hello &&
                start_svnserve &&
                git svn dcommit

* failed 1 among 2 test(s)

I hacked the test script to log the dcommit output to a file, and I see
this:

Committing to svn://127.0.0.1:5432 ...
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/SVN/Core.pm line 584.
Authorization failed:  at $gitsrc/t/../git-svn line 3329

(I replaced my git source dir full path with $gitsrc).

The version of libsvn-perl is:  1.5.0dfsg1-4

It could be another incompatibility introduced in SVN 1.5.0.

I'll try to dist-upgrade a machine to Lenny sometime in the next two
weeks so I can test; I'm pretty busy these days but if anybody else
wants to figure this out in the meantime, please do :)

Please let me know if you need more info.

I tried moving my ~/.subversion/config out of the way but it makes no
difference.  However, I agree we should block the user's home svn config
when running other dcommit tests now that we have auto-props.  Perhaps
just using the --config-dir option with an empty directory would be enough.

Thanks for the additional info!

-- 
Eric Wong