You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2013/05/02 00:37:56 UTC

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 Mon, Apr 22, 2013 at 10:21 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato@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