> -----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
request",
> 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 :-)),
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 request."
>
> 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
:-).
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
provide.
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
information.
Bert
Received on 2012-08-24 23:30:19 CEST