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
Received on 2017-09-01 17:24:34 CEST