I should point out this is on OSX. The results on Windows are more interesting:
1. Unlike OSX, on Windows the API completes without error. 2. However, the paths in the index are show ??? in place of UTF-8 3. But the content within the patch, shows up fine. So this seems like another data point in favor of just telling SVN to output as UTF-8 since it seems to only apply to the pathnames. Comments? On Thu, Sep 8, 2011 at 2:07 PM, Mark Phippard <markp...@gmail.com> 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. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ > -- Thanks Mark Phippard http://markphip.blogspot.com/
