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

RE: Making 'svn ls' faster (was: Re: [PATCH] Make ra_serf be more aggressive about closing directories in update)

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 24 Aug 2012 23:29:39 +0200

> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: vrijdag 24 augustus 2012 22:43
> To: Subversion Development
> Cc: Justin Erenkrantz; C. Michael Pilato; Dmitry Pavlenko
> Subject: Making 'svn ls' faster (was: Re: [PATCH] Make ra_serf be more
> aggressive about closing directories in update)
> On Fri, Aug 24, 2012 at 3:56 PM, C. Michael Pilato <cmpilato_at_collab.net>
> wrote:
> > On 08/10/2012 06:20 AM, Justin Erenkrantz wrote:
> >> FWIW, last week, I went down the path of trying to optimize the 'ls'
> >> client path - which issues two OPTIONS requests...which is kinda
> >> silly. but to remove it, requires that the RA open call also return
> >> the youngest revision. I rev'd all of the RA layers, but then got
> >> stuck in a maze of twisty calls inside libsvn_client to try and use
> >> that revnum to skip the later call which invokes OPTIONS again...I
> >> should probably post that incomplete patch before moving on to
> >> something else. =)
> On rereading this, I just remembered that I recently read something
> interesting about faster listing of the repository by using a "status
> instead of recursive "get-dir" calls.
> Here it is:
> http://vcs.atspace.co.uk/2012/07/15/subversion-remote-api-listing-
> repository-with-status-request/
> It's a blog entry by dmit10 (Dmitry Pavlenko -- hi there Dmitry :-)),
> several things, with examples, about SVN's remote API. It concludes with:
> "And I'll just notice that this approach should be faster than the
> used by 'svn list --depth infinity', because 'svn list --depth infinity'
uses a
> number of recursive 'git dir' calls (that result in a number of network
> requests). The approach based on the 'status' request and
> start_empty=TRUE allows to perform only one request."
> Just throwing this out here in case someone wants to look further at
> 'svn ls' faster. I have no clue if the above is even a good idea, if it
would work
> decently, how much work it would be, ... I'll leave the thinking to others

svn ls can also retrieve the lock status, which is a separate request.

All the separate requests on the client for recursing make 'svn ls' much
slower than requests that use a single report response.

For some cases 'svn status' is faster (such as the case used by subversive),
but svn status doesn't retrieve all the values the list api promises to
For the specific cases the status route will help, but for others it would
be more useful to use a new recursive ra api to retrieve the required

Received on 2012-08-24 23:30:19 CEST

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