Am 16.05.2014 18:57, schrieb Stefan Küng:
> On 16.05.2014 12:57, Sven wrote:
>> Today, I tried to use the SVN command line client from within TexStudio.
>> TexStudio invoked svn.exe with the following parameters:
>> svn.exe up --non-interactive c:\path_with_hebrew_letters\somefile.txt
>> The result was:
>> Skipped 'c:\path_with_hebrew_letters\somefile.txt'
>> Summary of conflicts:
>> Skipped paths: 1
>> As you can imagine, that's not very satisfying.
>> I then investigated. I opened a command prompt (cmd.exe, which is
>> unicode aware), and then tried the same command as TexStudio executed.
>> The result was the same (skipped path ...). As a workaround, I can "cd"
>> into the directory, and then use the command "svn up somefile.txt".
>> Another workaround is to renaming the folder with the hebrew characters.
>> My conclusion is that the svn command line client that ships with
>> tortoise SVN does not properly (if at all) support windows'
>> unicode-based path names.
> if you get "Skipped 'c:\path_with_hebrew_letters\somefile.txt'" and the
> chars you see there are the correct ones, then that implies that svn.exe
> is unicode aware.
They are the correct ones. At least in TexStudio. The Windows console is
not awfully good at displaying hebrew characters.
Also, how can you know how svn internally processes the paths? Even if
it manages to printing the folder name without mangling it up, it
doesn't mean that it is properly passed down the calls.
Basically, the "Skipping ..." message means, that svn thinks the file
I should probably use sysinternals filemon/process monitor to check
which path is passed to the actual OpenFile call that fails.
> you can try this:
> create a bat file with the following content:
> type "$1" > c:\testfile.txt
And which encoding would that file have? I'm pretty sure the encoding is
not UTF8/UCS2 or anything safe.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-05-16 18:07:14 CEST