bug#34350: 27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  34350@debbugs.gnu.org,  vincent.belaiche@gmail.com
> Date: Fri, 08 Feb 2019 11:08:36 -0500
> 
> I think intuitively, in terms of encoding for the file's contents the
> backends should always return a byte-sequence (i.e. with no-conversion)
> and the front-end should then decide how to decode it (e.g., obeying
> the -*- coding -*- cookie and such).

Why do we need to leave this to the front end?  It's a waste of cycles
to do decoding manually in Lisp, and it also pushes this obscure art
to application levels, where many Lisp programmers won't know how to
DTRT.

IMO, it's the other way around: by default the back-end should not
insist on any encoding, except where the VCS requires it, and it
should always by default decode the stuff it returns.  The front end
should disable code conversions when needed, and the back-end should
honor that.  This will mostly do TRT, because in the vast majority of
cases users do want eventually to have the stuff decoded, the number
of cases where we want the contrary is minuscule.

VC is just a fancy way of visiting files, so it should normally do the
same, i.e. decode.