On 24.12.2022 21:49, Karl Berry wrote:
The most classic example is "FILE.TXT" versus "file.txt". According to
To 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