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

Re: svn ls --search/pattern/glob/case-insensitive

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 1 Sep 2017 19:26:02 +0200

On Fri, Sep 1, 2017 at 5:55 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, Sep 01, 2017 at 04:24:28PM +0100, Julian Foad wrote:
>> And, for consistency, when matching paths with "svn log -vq --search..."
>> I would expect the same (I would not expect 'dog*' to match
>> lazy_dog.txt). At present the implementation does match it, because it
>> treats the pattern as a substring both when searching in the log message
>> and also when searching in the paths. I propose that one way to get
>> consistency is if we change "svn log --search" so it treats the pattern
>> as a substring in the log message but not in the paths.
>
> Yes, that makes sense. Here's an attempt at it.

I don't think that's a good idea. I've used "svn log -v --search"
before to search for "stuff" in the changed paths list, but I have
never considered that as globbing similar to what a unix shell would
do. I.e. it feels absolutely natural (to me) that "svn log --search"
just looks for a substring in "the entire output of the 'svn log'
command", without discerning between the different parts of that
output.

For example, I've recently searched for "(from" to find revisions with
"A+'ed" files or directories (to locate interesting examples to test
the tree conflict resolution :-)). I just guessed that would work, and
it did.

I think it would be weird to treat the changed paths list differently
from all the other output of "svn log".

If we'd like special matching for the "changed paths" list, I suggest
that should be done with a new option ("svn log -v --search-path" or
something), and "log --search" remains for just matching a substring
in the entire output. Hmm, but then maybe the "svn list" option should
also be named --search-path.

Tangentially (if we take a step back): I think an option name like
--filter or --include could be made to apply to more subcommands (in
the future):

* svn ls -R --filter '*.txt' ## list all *.txt files (recursively)
* svn cat -R --filter '*.txt' ## cat all the *.txt files (recursively)
* svn export --filter 'build.xml' ## export build.xml files into a
sparse directory structure

or

* svn ls -R --include '*.txt'
* svn cat -R --include '*.txt'
* svn export --include 'build.xml'

Of course only the first of those bullets is done (almost) ...
Maybe I'm dreaming a bit too much now :-)

-- 
Johan
Received on 2017-09-01 19:26:34 CEST

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