coding problem in filename

[ngong@…]

In case a filename uses some i18n character, the source can not be browsed through.

What I did:

introduced a new trac-mercurial project with coding is0-8859-15, pushed a lot of files into the VCS

What I expected:

To be able to use Browse Source in order to browse through the sources. If there were coding problems with file names I'd like to get notified, however, at least all files without such problems should be displayed - the one with problems anyhow.

What I got:

Some Python stack trace (appended) telling me about a coding problem. No file was shown.

Workaround:

Stick to ASCII coding of filenames.

[Christian Boos]

This is sort of "work in progress", as this will not work for 0.10 (sandbox/trac-mercurial branch), will work in a "brute force" way for 0.11 (sandbox/trac-mercurial-0.11 branch) and will improve further in the (sandbox/trac-mercurial-0.12 branch).

Please use Trac 0.11 (v0.11b2 for now) and the sandbox/trac-mercurial-0.11 branch if you can.

[anonymous]

I just got an

Trac detected an internal error:

UnicodeDecodeError: ('ascii', 'NFZPI/other/eMB/img/Neu-\xdcberf\xfchrung.txt', 32, 33, 'ordinal not in range(128)')

The traceback is:

File "/usr/local/lib64/python2.6/site-packages/Trac-0.11.5-py2.6.egg/trac/web/main.py", line 444, in _dispatch_request
  dispatcher.dispatch(req)
File "/usr/local/lib64/python2.6/site-packages/Trac-0.11.5-py2.6.egg/trac/web/main.py", line 205, in dispatch
  resp = chosen_handler.process_request(req)
File "/usr/local/lib64/python2.6/site-packages/Trac-0.11.5-py2.6.egg/trac/versioncontrol/web_ui/browser.py", line 360, in process_request
  'dir': node.isdir and self._render_dir(req, repos, node, rev),
File "/usr/local/lib64/python2.6/site-packages/Trac-0.11.5-py2.6.egg/trac/versioncontrol/web_ui/browser.py", line 406, in _render_dir
  entries = [entry(n) for n in node.get_entries()]
File "build/bdist.linux-x86_64/egg/tracext/hg/backend.py", line 694, in get_entriesFile "build/bdist.linux-x86_64/egg/tracext/hg/backend.py", line 602, in findnode

[Christian Boos]

See #8538.