[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

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


* 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 :-)

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

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