Norbert Unterberg wrote:
> I can add interesting "features" to the repo browser behaviour:
>
> #1
> - display a folder with a list of files in the repo browser
> - select one file with the mouse (hilight it)
> - press F5 (usually the "update" key)
> --> a '+' box appears in front of the file name
> - click on the '+' to expand the new tree
> --> you see the same file again as if it was in its own direcotry
> - select that file and press F5 again
> --> a new '+' box appeares below.
> - expand that '+' and you get
> Error * Failure to open '/trunk/some path name ...'
The problem you're seeing here is that TSVN has no way to check if an
URL points to a file or a folder. It just does an 'svn ls' and shows you
the result of that. So if you enter an URL to a file then you see what
you described above.
Ok, not quite true: TSVN _could_ check first if an URL points to a file
or a folder, but that would require another connection to the server,
doing an 'svn st' there and parse the result. This would mean for the
user to wait another 2-3 seconds until a folder is expanded in the
treeview - I just don't think this would be worth the effort.
> #2
> - Do the same as #1 with a file that has blanks in the file name
> --> when expanding the '+' you get a message "Error * URL non-existent in
> that revision
> BTW, the URL displayed in the edit box has blanks in it when you select
> the error message.
That's what users requested: to show the URL non-escaped (i.e. like a
normal windows path, with spaces instead of the %20).
> I have used a file:// url for this test.
>
> Maybe all the problems in this thread have to do with improper URL encoding,
> or with URL encoding that depends on the current OS code page? Note that the
> Czech windows versions do have a different code page than the western europe
> or US american versions.
No. The problems you describe here have nothing to do with the problems
reported before. You're problems occur because of TSVN treating URL's to
files as URL's to folders (as long as you don't enter such URL's
manually, this won't happen).
But the problems reported before happen because the server can't
decode/encode strings from and to UTF8 correctly. And that again happens
because TSVN sets the APR_ICONV_PATH environement variable in the shell
extension part to its own iconv directory. This directory now contains
the iconv library files for a statically linked version, also linked to
the MSVCR71.dll (the newest c-runtime library from MS). Now the guy
reporting this problem uses Subversion 1.1.x: that branch has the iconv
library compiled to link dynamically, not statically. And my guess is
that the version is also compiled with MSVC60.dll (the C-runtime lib of
VC6). So the server tries to convert a path/url from/to UTF8 by trying
to load the iconv modules (which are responsible for that conversion).
But that load fails because the iconv lib where APR_ICONV_PATH points to
is incompatible with the version it would need.
That problem with the iconv library has been discussed before. I even
sent _again_ a mail to the apr mailing list describing the problem and
what is needed to solve it - my mail (actually, I tried three times)
didn't even get through. Either the mail server just didn't work (what I
really doubt - I got no error mail back and I tried three times) or the
moderators thought that the mail wasn't important enough.
I guess I don't have a choice but to patch the iconv library myself and
use that patched version with TSVN...
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Jul 27 21:29:37 2004