RE: svn list support for listing directory entries only

The ‘list’ command is really only implemented at a high level, by retrieving the entries of each directory at a time and then filtering the results.

There is nothing you can do to really optimize this for directories without changing the ra layer and wire protocol for svn:// and http://.

I think it would make at least some users happy to add a ‘streamy’ list operation on the ra layer as it would optimize all the ‘svn ls’ cases, but nobody spend the time to fully implement this yet.

(I actually started an implementation of this some time ago, but never finished this as the compatibility work to support older servers was harder than I anticipated. But a lot of the missing ground work that made it that difficult back then is now implemented)

I’m not sure which Subversion client you use for your ‘svn ls’, but recently I compared an 1.6 an 1.8 client over http:// and the difference was *huge*, and 1.9 should be slightly better yet than 1.8. Perhaps just using a newer client might solve your performance problem.

Note that ‘svn ls’ was never an operation that Subversion was tuned for. Subversion works best on and between entire trees, while ‘ls’ is mostly a diagnostic tool. Some api users actually use the ‘svn status’ backend to quickly obtain a full tree of a repository in a single request in a faster way than ‘ls’

                Bert

From: Dan Ellis [mailto:danellis10_at_gmail.com]
Sent: maandag 5 mei 2014 19:56
To: Subversion Users
Subject: Re: svn list support for listing directory entries only

> The "depth" parameter is used in many places, not just in "svn list"; whatever enhancement you come up with must at least fit the other uses. Depth was invented to describe sparse working copies, and was only later adapted to other commands. For sparse working copies, "depth=dirs" probably doesn't make much sense.

> Once you've defined what "depth=dirs" means for all the commands that support depth, you're about 10% done ... you'd have to review the implementation for every use of the depth parameter and either add "depth=dirs" semantics, or make sure a reasonable error message is returned if that value is not supported by a particular command:

----
Yeah, I figured this would get shot down pretty quick since I mentioned a modification to a key parameter.  Completely understand and agree.  I've been digging around the API and I'm not sure I even see a call/parameter to fetch a directory listing only from the server.  Does with more knowledge of the API know if the API supports this, if so, any pointers (no pun intended).   I'm glad to call an API directly if that would work.
I'd also assume I won't get much traction with a new parameter unique to the list command (should it even be possible).
 
Thanks,
Dan