subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <>
Subject RE: svn list support for listing directory entries only
Date Mon, 05 May 2014 19:34:23 GMT
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’




From: Dan Ellis [] 
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).





View raw message