[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 22 Apr 2013 09:46:11 -0400

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

  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.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2013-04-22 15:46:45 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.