Re: 'svn list --search' feature complete?

[Julian Foad <ju...@apache.org>]

Julian Foad wrote:
> Quickly trying it out, I notice a bug. Matching is, presumably, I hope,
> intended to be case-insensitive, consistent with 'svn log --search'. It
> doesn't work properly: it seems not to match filenames containing
> upper-case characters:
> 
> $ svn list | grep -i "^co"
> COMMITTERS
> configure.ac
> contrib/
> 
> $ svn list --search 'co*'
> configure.ac
> contrib/
> 
> $ svn list --search 'CO*'
> configure.ac
> contrib/

Also the search term seems to be required to match the entire path, so I
need to write "co*" rather than just "co" to match "configure.ac". That
is inconsistent with "svn log --search" which looks for the pattern as a
substring even when matching paths. I think differences such as this are
bad.

- Julian

Re: 'svn list --search' feature complete?

[Julian Foad <ju...@apache.org>]

Johan Corveleyn wrote:
> On Mon, Aug 21, 2017 at 8:14 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Julian Foad wrote on Mon, 21 Aug 2017 14:09 +0100:
>>> Also the search term seems to be required to match the entire path, so I
>>> need to write "co*" rather than just "co" to match "configure.ac". That
>>> is inconsistent with "svn log --search" which looks for the pattern as a
>>> substring even when matching paths. I think differences such as this are
>>> bad.
>>
>> From the peanut gallery, I'm not sure about this.  When one greps log
>> messages, I think it is far more common to search for a _substring_ of
>> the log message than to ask for all revisions whose log messages are
>> strcmp()-equal to a particular string.
>>
>> On the other hand, with paths, it's plausible that one would know the
>> exact basename being sought, and wouldn't be interested in filenames
>> that contain that basename as a substring.
>>
>> Further, with glob patterns, if the CLI implements exact matching, users
>> can achieve either exact matching (default) or substring matching (by
>> adding * before and after the pattern), whereas if the client implemented
>> substring matching, there would be no way for users to request exact
>> matching: fnmatch() doesn't have an equivalent of regexes' ^ and $
>> anchors.
>>
>> But I haven't thought much about this.  There may well be logic to the
>> current behaviour that I'm overlooking.
> 
> FWIW, I agree with Daniel's argumentation here about doing exact
> matching with --list (and requiring *'s for substring matching).

So do I.

I also think, for consistency and for the reasons above, we should
change 'svn log --search' so that when searching in the changed paths it
works this way too. Then 'foo' and '*foo*' would have different meanings
when searching in the changed paths. When searching in fields such as
the log message, it would keep the existing behaviour whereby both of
those search terms would mean a substring search.

That would be a backwards-incompatible change, but to a non-prominent
and undocumented detail of the UI, and for good reasons. Does that make
sense?

- Julian

Re: 'svn list --search' feature complete?

[Johan Corveleyn <jc...@gmail.com>]

On Mon, Aug 21, 2017 at 8:14 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Julian Foad wrote on Mon, 21 Aug 2017 14:09 +0100:
>> Also the search term seems to be required to match the entire path, so I
>> need to write "co*" rather than just "co" to match "configure.ac". That
>> is inconsistent with "svn log --search" which looks for the pattern as a
>> substring even when matching paths. I think differences such as this are
>> bad.
>
> From the peanut gallery, I'm not sure about this.  When one greps log
> messages, I think it is far more common to search for a _substring_ of
> the log message than to ask for all revisions whose log messages are
> strcmp()-equal to a particular string.
>
> On the other hand, with paths, it's plausible that one would know the
> exact basename being sought, and wouldn't be interested in filenames
> that contain that basename as a substring.
>
> Further, with glob patterns, if the CLI implements exact matching, users
> can achieve either exact matching (default) or substring matching (by
> adding * before and after the pattern), whereas if the client implemented
> substring matching, there would be no way for users to request exact
> matching: fnmatch() doesn't have an equivalent of regexes' ^ and $
> anchors.
>
> But I haven't thought much about this.  There may well be logic to the
> current behaviour that I'm overlooking.

FWIW, I agree with Daniel's argumentation here about doing exact
matching with --list (and requiring *'s for substring matching).

-- 
Johan

Re: 'svn list --search' feature complete?

[Daniel Shahaf <d....@daniel.shahaf.name>]

Julian Foad wrote on Mon, 21 Aug 2017 14:09 +0100:
> Also the search term seems to be required to match the entire path, so I
> need to write "co*" rather than just "co" to match "configure.ac". That
> is inconsistent with "svn log --search" which looks for the pattern as a
> substring even when matching paths. I think differences such as this are
> bad.

From the peanut gallery, I'm not sure about this.  When one greps log
messages, I think it is far more common to search for a _substring_ of
the log message than to ask for all revisions whose log messages are
strcmp()-equal to a particular string.

On the other hand, with paths, it's plausible that one would know the
exact basename being sought, and wouldn't be interested in filenames
that contain that basename as a substring.

Further, with glob patterns, if the CLI implements exact matching, users
can achieve either exact matching (default) or substring matching (by
adding * before and after the pattern), whereas if the client implemented
substring matching, there would be no way for users to request exact
matching: fnmatch() doesn't have an equivalent of regexes' ^ and $
anchors.

But I haven't thought much about this.  There may well be logic to the
current behaviour that I'm overlooking.

Cheers,

Daniel