subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@apache.org>
Subject Re: svn ls --search/pattern/glob/case-insensitive
Date Fri, 01 Sep 2017 15:24:28 GMT
Stefan Sperling wrote:
> On Fri, Sep 01, 2017 at 03:01:33PM +0100, Julian Foad wrote:
>> (I'm unsure exactly what you meant there, stsp -- that seems to
>> contradict the previous paragraph, if 'svn log --search remains
>> case-insensitive.)
> 
> The most important point for me is that I don't think appending and
> prepending * globs is useful in the context of a path search with 'ls'.

Agreed.

> Consider a revision such as:
> 
> $ svn log -r 3 -v
> ------------------------------------------------------------------------
> r3 | stsp | 2017-09-01 16:12:23 +0200 (Fri, 01 Sep 2017) | 1 line
> Changed paths:
>    A /trunk/dog.txt
>    A /trunk/lazy_dog.txt
> 
> the quick brown fox jumps over the lazy dog
> ------------------------------------------------------------------------
> 
> The behaviour for log --search is that either '--search lazy' or
> '--search dog' will match this revision. This is fine because we are
> looking for log message output rather than path names.
> 
> $ svn log --search dog 
> ------------------------------------------------------------------------
> r3 | stsp | 2017-09-01 16:12:23 +0200 (Fri, 01 Sep 2017) | 1 line
> 
> the quick brown fox jumps over the lazy dog
> ------------------------------------------------------------------------
> $ svn log --search lazy
> ------------------------------------------------------------------------
> r3 | stsp | 2017-09-01 16:12:23 +0200 (Fri, 01 Sep 2017) | 1 line
> 
> the quick brown fox jumps over the lazy dog
> ------------------------------------------------------------------------

I agree this is fine when we are talking about searching in the *log
message*.

But when I talk about consistency between "list" and "log", I'm thinking
of the searching in *paths*, which should (and does) work like this:

$ svn log -vq --search quick
$ # no results

$ svn log -vq --search dog
Changed paths:
   A /trunk/dog.txt
   A /trunk/lazy_dog.txt


> However, when matching paths with 'svn ls' I would not expect 'dog*' to
> match lazy_dog.txt. The output is a list of paths, not a log message.
> I would expect matching to behave more like a unix shell does with ls(1).

Agreed.

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.

> The current behaviour as implemented by --pattern looks like:
> 
> $ svn ls -r3 --pattern 'dog*' ^/    
> $ svn ls -r3 --pattern 'dog*' ^/trunk
> dog.txt
> $ svn ls -r3 --pattern '*dog*' ^/trunk
> dog.txt
> lazy_dog.txt
> 
> The above behaviour looks good to me.
> 
> However, as you already pointed out, matching child path components
> seems to be impossible at present:
> 
> $ svn ls -r3 --pattern 'trunk/*'    
> $
> $ svn ls -R -r3 --pattern 'trunk/*' ^/ 
> $  
> 
> These should print:
> 
> trunk/dog.txt
> trunk/lazy_dog.txt
> 
> There is of course an interaction with --depth to consider.
> This already works:
> 
> $ svn ls -R -r3 --pattern '*dog*' ^/       
> trunk/dog.txt
> trunk/lazy_dog.txt
> $ svn ls -R -r3 --pattern '*trunk*' ^/
> trunk/
> $
> 
> Which suggests that matching happens after depth filtering.
> Perhaps a default depth should be chosen based on the pattern to allow
> patterns such as 'trunk/*' to match?
> 
> Regarding case:
> 
> If 'list --search' is designed to be case-insensitive, then this:
> 
> $ svn ls -r3 --pattern 'Dog*' ^/trunk
> $ 
> 
> should print:
> 
> dog.txt
[...]

All of the above looks good to me, apart from maybe we haven't nailed
the details of how paths starting with "^/" or "/" are matched.

- Julian


Mime
View raw message