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

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

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 24 Aug 2012 22:43:11 +0200

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
request", instead of recursive "get-dir" calls.

Here it is:

It's a blog entry by dmit10 (Dmitry Pavlenko -- hi there Dmitry :-)),
explaining 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
approach 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

Just throwing this out here in case someone wants to look further at
making '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 :-).

Received on 2012-08-24 22:44:02 CEST

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