On 24.12.2022 21:49, Karl Berry wrote:
The most classic example is "FILE.TXT" versus "file.txt". According toTo repeat: I'm not talking about case clashes and similar underlying filesystem problems; other people brought those up. I'm asking specifically about the failure of the unasked-for "UTF-8 conversion", which, so far as I can tell, is spontaneously induced by svn. There is no filesystem problem kind in this case (standard xfs). That is, I can touch/copy/remove/whatever the file that svn refuses to work with. -k
Yes there is. Windows file systems (well, at least NTFS) require file names in some sort of Unicode encoding. All the world is not Unix and even some Unix file systems store file names in UTF-8 (zfs comes to mind). Subversion does its best to conform to whatever the local rules are, but as you noticed, there are edge cases where that will cause problems.
The case you're describing, with some file names in SJIS and some in UTF-8, seems simply impossible to me, because we store file names in UTF-8 in the repository. So unless someone hacked the Subversion server, committing a SJIS file name should be impossible.
Regarding "spontaneously induced", well, this is how Subversion behaves, the reasons for that stem from the problem of cross-platform compatibility. It's also documented [1]. So assuming you can do some magic with file name encoding and expect Subversion to deal with it is, let's say, using the wrong tool for the job.
-- Brane [1] https://svnbook.red-bean.com/en/1.7/svn.advanced.l10n.html
