> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: zaterdag 20 april 2013 18:40
> To: dev_at_subversion.apache.org
> Subject: Re: log --search test failures on trunk and 1.8.x
>
> On 20.04.2013 18:30, Ivan Zhakov wrote:
> > On Sat, Apr 20, 2013 at 8:04 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> >> On Sat, Apr 20, 2013 at 7:54 PM, Branko Čibej <brane_at_wandisco.com>
> wrote:
> >>> On 20.04.2013 17:42, Stefan Sperling wrote:
> >>>> On Sat, Apr 20, 2013 at 07:26:06PM +0400, Ivan Zhakov wrote:
> >>>>> On Sat, Apr 20, 2013 at 2:27 PM, Stefan Sperling <stsp_at_apache.org>
> wrote:
> >>>>>> How is lower-casing a multi-byte UTF-8 character going to help?
> >>>>>> Won't the lower-case equivalent still be a multibyte character
> >>>>>> and trigger the overflow check in Visual Studio?
> >>>>>>
> >>>>> Because in this case we can call apr_fnmatch without
> >>>>> APR_FNM_CASE_BLIND, avoid tolower calls and get case-insensitive
> >>>>> match.
> >>>> Are we going to implement our own code to transform a string
> >>>> to lower case? Or do we already have such functions for UTF-8 strings?
> >> No, we don't have such functions. We can try to convert UTF-8 string
> >> to wchar_t and use towlower(), but probably it's overkill.
> >>
> >>> We aren't and we don't, on trunk; but the wc-collate-path branch does
> >>> have code that can do Unicode-aware case folding through utf8proc.
> >>>
> >> It looks like a best solution.
> >>
> > I've looked to wc-collate-path branch and it seems utf8proc stuff is
> > useful. Can we merge utf8proc to trunk?
>
> I was going to wait until the 1.8-RC specific changes get finished, to
> make merging easier. I'd also planned to replace a bunch of homegrown
> UTF-8 processing functions with utf8proc eventually.
What locales is utf8proc going to provide in-tree?
If we just get case folding for the common western cases we can just write some simple case folding in 'svn'. I would say adding a build requirement like this for such a specific 'svn'-client feature is a bit overkill in this stage of release.
Adding all the required plumbing now to make this a supported api for all future releases after branching 1.8...
I'd rather pull the case insensitive search part of this new in 1.8 search feature and do it right in 1.9.
Bert
Received on 2013-04-21 13:54:50 CEST