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

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

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 23 Aug 2017 15:52:52 +0200

On Mon, Aug 21, 2017 at 8:14 PM, Daniel Shahaf <d.s_at_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
Received on 2017-08-23 15:53:35 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.