On 29.08.2017 12:22, Johan Corveleyn wrote:
> On Tue, Aug 29, 2017 at 12:08 PM, Stefan Fuhrmann <stefan2_at_apache.org> wrote:
>> On 18.08.2017 13:36, Johan Corveleyn wrote:
>>>
>>> On Sun, Jan 29, 2017 at 10:35 AM, Stefan Fuhrmann <stefan2_at_apache.org>
>>> wrote:
>>>>
>>>> On 24.01.2017 12:20, Stefan Sperling wrote:
>>>
>>> ...
>>>>>
>>>>> I would like to get an 1.10.0 alpha1 released in February. Unless I hear
>>>>> objections I will start rolling this alpha release from trunk and call a
>>>>> vote on it soon.
>>>>
>>>>
>>>>
>>>> Originally, I wanted to complete the get_list API before the alpha
>>>> release but I can't make any commitments. So, it is probably better
>>>> to roll the alpha with whatever is on /trunk at that time.
>>>>
>>>> -- Stefan^2.
>>>
>>>
>>> Hi Stefan2,
>>>
>>> Is the current state of the new get_list API complete on trunk now? Is
>>> the 'svn list --search' feature useable / good enough for beta?
>>>
>>> Context: on IRC we were talking about releasing a 1.10 beta, so this
>>> crossed my mind as one of the new features that might not be complete
>>> yet.
>>>
>>> BTW: 'svn list --search' isn't described in the release notes yet (and
>>> neither in CHANGES I believe).
>>>
>>
>> Sorry that had fallen off the edge of the disk for
>> the last couple of weeks. Been super busy and then
>> went fully off the grid for the last two weeks.
>>
>> r1806548 fixes the inconsistency that Julian found.
>
> Are you sure? As I understood from Julian's mail, the problem with the
> case-sensitivity really seemed like a bug: files with uppercase
> characters were simply not found, not even if the pattern was spelled
> out in uppercase. See the last one here below:
>
>> $ svn list | grep -i "^co"
>> COMMITTERS
>> configure.ac
>> contrib/
>>
>> $ svn list --search 'co*'
>> configure.ac
>> contrib/
>>
>> $ svn list --search 'CO*'
>> configure.ac
>> contrib/
>
> So that looks like: you tried to make it case-insensitive (by
> converting the pattern to lowercase internally), but it doesn't work
> (because the paths are not converted similarly or something).
>
> (I haven't tested it myself)
The thing is that --search "normalizes" the given patterns
to lower-case and handles accents. --patterns only converts
to UTF-8.
> Orthogonally: I think case-insensitive matching would be nice to have
> as well (either always, or optionally with some flag / pattern prefix
> / ...). Use case: Windows user base, trying to search for files with
> an extension, like *.PNG, *.png, ...
Not sure that will work on the server-side.
-- Stefan^2.
Received on 2017-08-29 13:09:55 CEST