On 09/08/2011 02:07 PM, Mark Phippard wrote:
> This is a JavaHL issue. See the attached patch which resolves the
> problem I face.
>
> If I use the JavaHL diff API to produce a patch it fails if there are
> paths in the patch with UTF8 characters in the name. Here is an
> example of the Exception:
>
> Invalid argument
> svn: Can't convert string from 'UTF-8' to native encoding:
> svn: Index: ?\230?\181?\139?\232?\175?\149?\230?\150?\135?\228?\187?\182.txt
> ===================================================================
>
> RA layer request failed
> svn: Error reading spooled REPORT request response
>
>
> The problem seems to be that JavaHL creates the output file for the
> patch with the encoding of SVN_APR_LOCALE_CHARSET. If I change this
> to "utf-8" as shown in the patch then the method works.
>
> The command line client from the same system works fine.
>
> How do people feel about this? Does it make sense that JavaHL should
> create the patch file with UTF-8 encoding? I tend to think it does,
> but thought I would raise the question here.
Why does the command-line client work? Does it not also use the locale
encoding for its diff headers? At any rate, consistency between the
behaviors of the relevant Java and C APIs seems like a reasonable goal.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-09-08 20:28:14 CEST