On Wed, Jun 2, 2010 at 5:29 PM, Branko Čibej <[email protected]> wrote: > > It's not really very magic. :) We have four sets of conversions: > external to/from UTF-8, UTF-8 to/from filesystem path. I believe I > misled you a bit.
Brane, thanks for the concise explanation of the assumed design. unfortunately for z/OS, that isn't what the code is really doing. The assumed UTF-8 in the middle is really a hodge-podge of real UTF-8 and native literal strings and characters. But I was encouraged to see a recent post asking how to test the encoding for a patch on an ASCII box to make sure it was correct. On Unix, external and filesystem-path use the same > encoding; on Windows, filesystem-path is UTF-8 (converted as necessary > to UTF-16 by APR). So we don't actually have a different set of > functions just for console output conversions; but they could be added. > Conversion from command-line parameters and interactive input (e.g., > passwords) to the internal UTF-8 encoding are tricky, too. I think we do > them incorrectly in general on Windows, assuming too much about the > external encoding. > > String literals are the worst part because no conversions are performed > on them ... *nods* but we could add something to the _() macro and fix a lot of it. > you mentioned NLS: all our translation files are in UTF-8, > so if the literals within _() are in EBCDIC, none of the translations > will work. Awfully hairy problem there. > yep. I think the internal encoding could be made consistent without too much trouble. However, a simpler solution for now to get the basic svn functionality out there for z/OS has already been done. It is to ignore the mixed encoding and wave a magic wand and make EBCDIC go away internally to svn. I tried that earlier without much luck, but it turns out there is a much more potent magic wand than the one I used, as used by this patch posted to the svn users list in 2006: http://svn.haxx.se/users/archive-2006-11/0063.shtml I started playing with this patch. so far, so good, but then I hit some minor problem because I used 1.5.6 as my base. then &dayjob took me away from it. the patch needs work before it could be committed, as the author stated. Dan, though you might be interested :) Greg
