Re: [PATCH] possible improvement to svn log with "forward" revision range (issue 3830)

Well, since issue 3931 was fixed today
('svn log' is returning log of unrelated path when peg revision is not related to operative revision)
i revisited my patch for issue 3830.

+ /* try fetching ra_session again
+ * this time with modified revision argument.
+ * @todo modify already existing ra_session if possible? */
+ err = svn_client__ra_session_from_path(&ra_session, &ignored_revnum,
+ &actual_url, ra_target, NULL,
+ &peg_rev, &session_mod_rev,
+ ctx, pool);

I don't know if it is possible to modify an already existing ra_session instead of opening a new for different revisions.
If yes, please come up with an short description, so that performance would be improved.

> This looks expensive as well. It's a round trip to find out if the path
> has been deleted. Would it be more efficient to try the log and only do
> this if the log fails?

I don't see a way to achieve this.
If svn_ra_get_log2 is executed with the original revision range it will return the log for an unrelated path!
So there is no way to call it first and only in case of errors check for deleted revision.
(I am also not sure if svn_ra_get_log2 needs then to be fixed or if it is sufficient if these checks are performed "outside" in svn_client_log5.)

I have updated and attached the patch for issue 3830.
It now deals correctly with all cases like forward/backward ranges, number/HEAD/BASE/dates.
May be someone might again take a closer look.

The initial idea was to enable forward revision logs like N:HEAD even if the path has been deleted in between.
In the meantime i do see some problematic cases what would be the expected result for a svn log command.

E.g. see the modified unit test about what to expect from log-commands when the effective revision range (after reducing it based on deleted revision) does no more cover any revisions.
I will send another mail about this problem later.

Dirk