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
From: Paul Burba <ptburba_at_gmail.com>
Date: Mon, 22 Apr 2013 13:22:43 -0400
On Sat, Apr 20, 2013 at 5:00 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
The "few before"? There is only one (rr1469515) that I see. Are you
> (The path resolving via svn_client__repos_locations() is on the file system layer essentially the same thing as walking the history on the filesystem layer.)
How exactly would svn_client__repos_locations be useful? Do you mean
> libsvn_client's log operation is already a very slow operation over high latency links with mod_dav and this patching with extra ra requests is making it worse and worse.
I reverted r1469515 and r1469982 (excepting the new log tests of
> Performing this operation once should improve the log performance considerable, making the multi range version much better for script and api users.
On Mon, Apr 22, 2013 at 9:46 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
You too mean svn_ra_get_location_segments or svn_ra_get_locations I assume?
> uses none other than the 'log' functionality.
> So I see this:
-- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba On Mon, Apr 22, 2013 at 10:21 AM, Bert Huijben <bert_at_qqmail.nl> wrote: > > >> -----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 > -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburbaReceived on 2013-04-22 19:23:15 CEST
This is an archived mail posted to the Subversion Dev mailing list.