convert: correctly convert paths to UTF-8 for Subversion
The previous code using encoding.tolocal() only worked by chance in these
situations:
* The string is ASCII: The fast path was triggered and the string was returned
unmodified.
* The local encoding is UTF-8: The source and target encoding is the same.
* The string is not valid UTF-8 and the native encoding is ISO-8859-1: If the
string doesn’t decode using UTF-8, ISO-8859-1 is tried as a fallback. During
`hg convert`, the local encoding is always UTF-8. The irony is that in this
case, encoding.tolocal() behaves like what someone would expect the reverse
function, encoding.fromlocal(), to do.
When the locale encoding is ISO-8859-15, trying to convert a SVN repo `/tmp/a€`
failed before like this:
file:///tmp/a%C2%A4 does not look like a Subversion repository to libsvn version 1.14.0
The correct URL is `file:///tmp/a%E2%82%AC`.
Unlike previously (with the ISO-8859-1 fallback), decoding the path using the
locale encoding can fail. In this case, we have to bail out, as Subversion
won’t be able to do anything useful with the path.
#require serve
$ cat <<EOF >> $HGRCPATH
> [extensions]
> schemes=
>
> [schemes]
> l = http://localhost:$HGPORT/
> parts = http://{1}:$HGPORT/
> z = file:\$PWD/
> EOF
$ hg init test
$ cd test
$ echo a > a
$ hg ci -Am initial
adding a
invalid scheme
$ hg log -R z:z
abort: no '://' in scheme url 'z:z'
[255]
http scheme
$ hg serve -n test -p $HGPORT -d --pid-file=hg.pid -A access.log -E errors.log
$ cat hg.pid >> $DAEMON_PIDS
$ hg incoming l://
comparing with l://
searching for changes
no changes found
[1]
check that {1} syntax works
$ hg incoming --debug parts://localhost
using http://localhost:$HGPORT/
sending capabilities command
comparing with parts://localhost/
query 1; heads
sending batch command
searching for changes
all remote heads known locally
no changes found
(sent 2 HTTP requests and * bytes; received * bytes in responses) (glob)
[1]
check that paths are expanded
$ PWD=`pwd` hg incoming z://
comparing with z://
searching for changes
no changes found
[1]
check that debugexpandscheme outputs the canonical form
$ hg debugexpandscheme bb://user/repo
https://bitbucket.org/user/repo
expanding an unknown scheme emits the input
$ hg debugexpandscheme foobar://this/that
foobar://this/that
expanding a canonical URL emits the input
$ hg debugexpandscheme https://bitbucket.org/user/repo
https://bitbucket.org/user/repo
errors
$ cat errors.log
$ cd ..