svn log - combining 'search' and 'limit'

[Daniel Becroft]

Hi,

I've come across something which seems to be working not as expected, but I'm not sure it is a bug.

At the moment, I can do `svn log --search "Foo"` to get all the log messages containing "Foo", and `svn log --limit 10` to get the last 10 log messages.

I expected that if I combined these (for example, `svn log --search "Foo" --limit 10`), that I would get the last 10 log messages that contained the search criteria, however it only showed those log messages in the last 10 that contained "Foo". If the latest log message that contained "Foo" was number 11, nothing would be displayed.

Real-world example, using:

>svn log https://svn.apache.org/repos/asf/subversion/trunk --search "SEGV" --limit 1

I would expect to see r1798157, however I don't see anything (as the revision returned from --limit 1 is not it).

Cheers,

Daniel B.

[Branko Čibej]

It's more of a conceptual misunderstanding. --limit N tells 'svn log' to
display _at most_ N log messages in the given revision range. Adding a
--search option does not change the meaning of --limit; it only filters
the results within the log messages defined bu the path, --limit and
--revision (range) options.

-- Brane

[Daniel Shahaf]

Daniel Becroft wrote on Wed, 28 Jun 2017 07:40 +0000:
> I expected that if I combined these (for example, `svn log --search "Foo"
> --limit 10`), that I would get the last 10 log messages that contained the
> search criteria, however it only showed those log messages in the last 10
> that contained "Foo". If the latest log message that contained "Foo" was
> number 11, nothing would be displayed.

The --limit filter is implemented at a different layer to the --search
filter.

The --search filtering is implemented directly in the command-line
client; the --limit filter is implemented in the library. They are
implemented orthogonally, so the --search operates only on the results of
--limit, as you observed.

The change you propose certainly makes sense from the perspective of
somebody who uses --search and wants to limit its output. However, from
the opposite perspective, of somebody who uses --limit=500 and then
wants to filter _that_ output to log messages that contain "needle", the
existing behaviour is the desired one. That is: both 'foo | head |
grep bar' and 'foo | grep bar | head' are reasonable use-cases.

A further complication is that applying --limit to the results of
--search would require either downloading the whole log to the client,
or pushing the "search pattern" logic to the server.

tl;dr: I agree that your use-case is valid, but I'm not sure how to
support it.

Cheers,

Daniel