On Tue, Feb 23, 2010 at 3:37 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Got the following bug report from one of our CollabNet Asia peers. Â I've not
> Â attempted to reproduce the problem myself. Â This bug was experienced using
> a 1.6.x client, but I don't know exactly which 'x'. Â Anybody else seen similar?
Yeah, it's easy to reproduce with trunk.
>
> --------------------------------------------------------------------
>
> serf looks having problem on handling double byte directory name. For
> example, if you have the following structure in your repository:
s/serf/ra_serf/
..
>
> "svn list http://path_to_repo/%e6%97¥" returns an error like:
> svn: The PROPFIND response did not include the requested resourcetype value
This is what happens:
On the PROPFIND request "PROPFIND
/svn/tst/!svn/rvr/285/trunk/%E6%97%A5 HTTP/1.1", the server responds
with the propstat xml response. The interesting parts of that response
are:
..
<D:href>/svn/tst/!svn/rvr/285/trunk/%e6%97%a5/</D:href>
..
<lp1:checked-in><D:href>/svn/tst/!svn/ver/285/trunk/%E6%97%A5</D:href></lp1:checked-in>
..
<D:href>/svn/tst/!svn/rvr/285/trunk/%e6%97%a5/abcdefg</D:href>
..
<lp1:checked-in><D:href>/svn/tst/!svn/ver/285/trunk/%E6%97%A5/abcdefg</D:href></lp1:checked-in>
As you can see, the æ—¥ character is encoded as either %E6%97%A5
(capital E) or %e6%97%a5 (lowercase e). This shouldn't be a problem,
but ra_serf uses these paths as keys in a hash table to later retrieve
them. It turns out they are first stored as /path/%E6%97%A5, and then
later retrieved as /path/%e6%97%A5, which obviously doesn't work as
paths are handled case sensitive.
These paths are canonicalized before being used, but
svn_uri_canonicalize doesn't touch the encoded characters. Maybe it
should just convert those letters to lowercase? I don't really see a
better fix.
Lieven
Received on 2010-02-24 23:40:16 CET