Subversion bridge fails with filenames containing + characters

[ryandesign]

This is a bug report for GitHub.

The GitHub Subversion bridge doesn’t work properly with files whose names contain the + character.

Using subversion 1.13.0 on macOS 10.13.6, I used “svn mv” to rename an existing file. The new filename contained a + character. After being committed to git, the + character in the filename changed to either the space character or the three characters %20; looking at it in different places showed different results:

cclient: Fix implicit function decls; cleanup

I corrected the filename using the GitHub web interface:

cclient: Fix patchfile name

but hopefully you can fix this bug in the Subversion bridge. Thanks.

[ryandesign]

Here’s the terminal output of the commit, showing no sign that the server did not accept my intended filename:

$ svn ci
Sending        Portfile
Adding         files/allow-plaintext-passwords.patch
Adding         files/fix-pam-paths-for-10.6+.patch
Adding         files/implicit.patch
Adding         files/openssl-1.1.patch
Deleting       files/patch-03-openssl_1_1
Deleting       files/patch-Makefile
Deleting       files/patch-Makefile-fixpam
Transmitting file data ....done
Committing transaction...
Committed revision 178235.

[dwschmid]

Just hit this problem too. This needs fixing in the subversion bridge. Folders that are called locally
+subfolder
end up on GitHub with the + replaced with a space when committed with svn. This used to work previously, i.e. I have repos that were committed with svn and have the leading + character, but now it is broken. Seems independent of local operating system and svn client details.