[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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: Wed, 1 May 2013 18:37:56 -0400

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.

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
Received on 2013-05-02 00:38:27 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.