On Fri, Aug 24, 2012 at 3:56 PM, C. Michael Pilato <cmpil...@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 :-). -- Johan
