"C.A.T.Magic" <c.a.t.magic@gmx.at> writes:
> 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
> it:
Fixing the memory consumption bug is unlikely to require a protocol
change. Fixing the slowness might require a protocol change, though.
I don't know about all these enhancements and new features. But if we
add a new RA interface, we should try to make the interface open to
new features, and your list might be a good place to start for ideas.
Can you record them in the issue?
Thanks,
-Karl
> -) 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
> /tags/joe/Source
> /tags/sally/Source
> /tags/jack
>
> -) please allow listing only up to a certain depth, e.g.
> svn ls ($REPOS)/tags --depth 3
> /tags/joe/Tag-1.2.3
> /tags/sally/Tag-1.1.3
> /tags/sally/Tag-1.5.3
> /tags/jack/Tag-1.4.2
>
> svn ls ($REPOS)/tags --depth 2
> /tags/joe
> /tags/sally
> /tags/jack
>
> -) allow listing of folders matching a special pattern
> e.g.
> svn ls ($REPOS)/tags --match /tags/*/*/Source/foo.cpp
> /tags/joe/Tag-1.2.3/Source/foo.cpp
> /tags/sally/Tag-1.1.3/Source/foo.cpp
> /tags/sally/Tag-1.5.3/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...)
>
>
> thanks
> c.a.t.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 6 19:02:48 2004