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:danelli...@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
