> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: zondag 21 april 2013 14:05
> To: Bert Huijben
> Cc: 'Branko Èibej'; dev_at_subversion.apache.org
> Subject: Re: log --search test failures on trunk and 1.8.x
>
> On Sun, Apr 21, 2013 at 01:53:43PM +0200, Bert Huijben wrote:
> > I'd rather pull the case insensitive search part of this new in 1.8
search
> feature and do it right in 1.9.
>
> What's the issue with the current implementation apart from the
> test failures on Windows?
What I try to avoid is adding the new api's in libsvn_subr which we would
have to maintain indefinitely even though we might not use them from
anywhere except 'svn'
>
> The behaviour of 'svn log --search' regarding case-sensitivity
> isn't even documented, so we're not really prosmising anything.
>
> It is possible that some users who are using languages other than
> English will complain, since ASCII is being matched case-insensitively,
> and all other characters are being matched case-sensitively.
> But this is due to a missing feature in APR's implemention of fnmatch().
>
> Provided we can fix the 1.8.x tests on Windows I see no reason to
> change our implementation of log --search. We can simply wait for
> APR to grow the necessary support for multibyte strings.
We currently trigger undefined behavior...This is something completely
different than 'trying to fix some tests'
Undefined behavior might be that it works on the buildbot, but formats every
users harddisk.
An easy fix could be that we perform case normalization in 'svn' itself by
just converting [a-z] to [A-Z] in all the strings before passing them to
apr. (Normalizing to upper case is in general much safer then normalizing to
lower case. Not normalizing and using a proper compare function is the best
fix)
Note that this is unrelated from the utf normalization problems what we
tried to use utf8proc for. (Which is a problem that is resolvable by a fixed
rules table, while case folding via a locale isn't)
I don't think we should bump the required apr version to fix this problem
and should try to fix this in 'svn' instead.
APR currently doesn't document a specific character encoding and/or locale
for its fnmatch function, so a patch to make it comply to a specific
character encoding and locale is probably not the right fix.
Bert
Received on 2013-04-21 14:48:15 CEST