Hi subversion developers,
I'd really really like to see issue #1742 fixed
at least for the 1.1 release.
the issue is about svn ls -R being
quite unusable over http, because it is
incredible slow (doing repeated nonrecursive listing
requests from the client side?) and consuming
huge amounts of memory (why?).
since the fix of #1742 will already require
an extension of the protocol I'd like to
suggest several more features when extending
-) please allow listing of "folders only" (no files)
this is to save bandwith when e.g. listing a tags folder.
svn ls ($REPOS)/tags --dirs
-) please allow listing only up to a certain depth, e.g.
svn ls ($REPOS)/tags --depth 3
svn ls ($REPOS)/tags --depth 2
-) allow listing of folders matching a special pattern
svn ls ($REPOS)/tags --match /tags/*/*/Source/foo.cpp
( /tags/jack/Tag-1.4.2 not listed because foo.cpp is not there )
maybe even including
svn ls tags --match /tags/*fix*/BrokenFile.cpp
svn ls tags --match /tags/***/*fix*/*.cpp
with *** meaning any number of directories inbetween.
( or ofcourse, standard unix regexps...
though they are annoying with the \/ escaping on pathes )
-) allow searching for a file by its 'id'
svn ls tags /tags --id /trunk/Source/foo.cpp
this would (at server side) get the node id of foo.cpp,
then list all folders below /tags containing
copies of this file (node). precisely answering the
question 'which tags/copies/branches exist of that file'.
speed is not much of an issue if one at least CAN ask
that question. I even think it would still be quite fast
if implemented as a dumb recursive repos-tree search
at server side.
-) show the output during the transfer and allow ctrl-c
to abort it immediatedly.
I guess I don't need to explain why I'd like to have
svn ls -R (speed, mem) fixed and why i'd love
these extended commands implemented at the server side
(if not all, then at least part of them...)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed May 5 00:26:13 2004