> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: maandag 22 april 2013 15:46
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1469982 - in /subversion/trunk/subversion:
> include/private/svn_client_private.h libsvn_client/log.c libsvn_client/ra.c
> tests/cmdline/log_tests.py
>
> On 04/20/2013 05:00 AM, Bert Huijben wrote:
> > Instead of patching more and more corner cases with individual extra ra
> > calls I think svn_client_log should call svn_client__repos_locations()
> > once to obtain the history of the path to look at over the entire range
> > of versions. (=over MAX(rev):MIN(rev)) and then use that information
> > directly as the paths for the rest of the log calls.
>
> Agreed. Was thinking exactly the same thing.
>
> I wonder, though: isn't this rev-range support better situated in the RA
> layer itself, extended up to the server? I ask because IIRC, the fallback
> implementation of svn_ra_get_repos_locations() uses none other than the
> 'log' functionality.
>
> So I see this:
>
> BEST CASE: client's RA layer and server can handle log-with-ranges
>
> FALLBACK 1: client RA layer works around server's lack of log-with-ranges
> support by using get_locations() and a series of log requests
I think this should work for 1.5+ servers.
> FALLBACK 2: client RA layer works around server's lack of log-with-ranges
> support and lack of get_locations support by using a single
> log request from which disinteresting revisions are merely filtered
> out.
+1
Given that we already branched for 1.8 I would suggest backporting FALLBACK 1 to 1.8 and leaving the BEST CASE for 1.9.
But maybe if somebody starts now, he/she can get it ready for 1.8.
(Would be nice to see the performance improvements sooner)
The fallback 1/2 cases can be implemented as a bugfix even for 1.7 if there is enough interest as they don't change public APIs.
Bert
Received on 2013-04-22 16:22:23 CEST