svn on z/OS [was; [PATCH] use APR's ctypes on EBCDIC systems]

[Greg Ames <am...@gmail.com>]

On Wed, Jun 2, 2010 at 5:29 PM, Branko Čibej <br...@xbc.nu> 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