On 16.05.2014 18:12, Sven wrote:
> 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.
You said that cmd.exe is unicode aware. If it is then it can show those
characters just fine. Only if it isn't then it can't show those 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.
Because every path passed to svn is converted to utf8 on input and only
utf8 strings are passed around internally in the svn lib.
Also the fact that it works if you 'cd' into that dir clearly shows that
svn.exe can deal with such paths, because not only are the paths
converted to utf8 on input but also all relative paths are first
converted to full absolute paths before they're passed to the internal
> Basically, the "Skipping ..." message means, that svn thinks the file
> doesn't exist.
Nope. Skipping simply means the file was skipped. There can be other
reasons a file is skipped.
> 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.
that doesn't matter: the content should be the same.
Just try it.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-05-16 18:17:19 CEST