On 12/30/2022 4:40 PM, Karl Berry wrote:
Well my point is that this would not work everywhere.
How can "store as bytes" not work (be implementable?) everywhere? I'm
missing something.
I seem to remember an earlier message in the thread mentioning
Windows... where filenames are natively
On Fri, Dec 30, 2022 at 5:41 PM Karl Berry wrote:
>
> Well my point is that this would not work everywhere.
>
> How can "store as bytes" not work (be implementable?) everywhere? I'm
> missing something.
18 years ago when Paul Burba and I were working on porting SVN to run
on OS/400 this feat
Well my point is that this would not work everywhere.
How can "store as bytes" not work (be implementable?) everywhere? I'm
missing something.
When stored/returned as bytes, certainly a filename might look like
garbage when presented to the user, depending on their locale, what the
filename
On 26.12.2022 22:26, Karl Berry wrote:
I certainly don't expect such fundamental behavior to change, but I
can't help but respond a little. Just ignore me :).
All the world is not Unix
...
the problem of cross-platform compatibility.
Of course. Precisely the reason why stor
It's also documented [1].
https://svnbook.red-bean.com/en/1.7/svn.advanced.l10n.html
Thanks. I failed to find that. Now I understand.
I certainly don't expect such fundamental behavior to change, but I
can't help but respond a little. Just ignore me :).
All the world is not Unix
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-fo
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 c
On Fri, Dec 23, 2022 at 4:35 PM Karl Berry wrote:
>
> Perhaps «export LC_ALL=C.UTF-8», if your platform has that encoding?
>
> Yes, thanks, that is one of the workarounds. But that's not my
> question.
>
> My question is, why can't svn just treat the filenames as bytes? I
> remain baffled by t
Perhaps «export LC_ALL=C.UTF-8», if your platform has that encoding?
Yes, thanks, that is one of the workarounds. But that's not my
question.
My question is, why can't svn just treat the filenames as bytes? I
remain baffled by the need to unconditionally convert to/from UTF-8 (or
any other
On Fri, Dec 23, 2022 at 3:58 AM Daniel Sahlberg
wrote:
>
> Den tors 22 dec. 2022 kl 23:40 skrev Karl Berry :
>>
>> Clearly those UTF-8 code points cannot be "converted" by svn to the
>> 7-bit ASCII locale that is "C". Fine; I don't expect it to. Is there a
>> way to force svn to complete the chec
Daniel Sahlberg wrote on Fri, 23 Dec 2022 08:58 +00:00:
> Example: Commit a file with ? (questionmark) in the filename on Linux and
> checkout the file on Windows.
Or case-colliding files:
url=`svn info --show-item=url`
svn mkdir -- $url/foo $url/FOO
svn up
> This is a case where a conversion mi
Karl Berry wrote on Thu, 22 Dec 2022 22:40 +00:00:
> A file with a name that has some "eight-bit" UTF-8 bytes (fn...-utf8.tex)
> was committed to one of my repositories. When I try to check it out in
> the C locale, svn complains:
>
> $ echo $LC_ALL
> C
> $ svn update
> svn: E22: Can't convert
Den tors 22 dec. 2022 kl 23:40 skrev Karl Berry :
> Clearly those UTF-8 code points cannot be "converted" by svn to the
> 7-bit ASCII locale that is "C". Fine; I don't expect it to. Is there a
> way to force svn to complete the checkout anyway? That is, just check
> out the file and let the name
A file with a name that has some "eight-bit" UTF-8 bytes (fn...-utf8.tex)
was committed to one of my repositories. When I try to check it out in
the C locale, svn complains:
$ echo $LC_ALL
C
$ svn update
svn: E22: Can't convert string from 'UTF-8' to native encoding:
svn: E22: fn{U+00B1}{U
14 matches
Mail list logo