On Mon, Apr 22, 2013 at 10:21 AM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: C. Michael Pilato [mailto:cmpil...@collab.net] >> Sent: maandag 22 april 2013 15:46 >> To: Bert Huijben >> Cc: dev@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.
Implemented "Fallback 1" in r1478220 (with a minor cleanup in r1478221) -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba > 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
