[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: log --search test failures on trunk and 1.8.x

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Sun, 21 Apr 2013 19:03:49 +0400

On Sun, Apr 21, 2013 at 4:05 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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?
>
Search is case-insensitive for only latin characters. This is really confusing.

> The behaviour of 'svn log --search' regarding case-sensitivity
> isn't even documented, so we're not really prosmising anything.
>
Ok, what about make 'log --search' case-sensitive in 1.8 and implement
'log --isearch' in 1.9 when we merge utf8proc stuff to trunk?

> 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().
>
Users do not care whether this APR or Subversion problem. They just use svn.exe.

> 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.
>
There is really small chance that this issue will be fixed in near
future. For proper fix APR should link utf8proc or alternative
library for true case-folding.

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-04-21 17:04:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.