subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Ellis <>
Subject Re: svn list support for listing directory entries only
Date Sun, 04 May 2014 02:25:23 GMT
On Sat, May 3, 2014 at 7:16 PM, Ryan Schmidt <
> wrote:

> On May 3, 2014, at 20:13, Dan Ellis wrote:
> > The svn command line list command currently accepts --depth arguments of
> files, infinity, and immediates (and empty, but that is really a no-op).
>  I'm in need of being able to list directory entries only in a repository,
> but I'm not sure there is any good way to accomplish that as-is.  I've
> search the lists and can only find articles about how folks have grep'ed
> the output or hacked list.c to only return directory entries (which is
> really just an inelegant grep anyways since the server still will be
> sending the data).
> >
> > Is there a way, or consideration from the developers to add a feature,
> to fetch only directory entries from a repo?  Perhaps a --depth dirs
> (opposite of --depth files) option.  If there is no off the shelf way
> and/or the developers are against (or don't see enough need) to implement
> this, would there be any advise on how to accomplish this with a patch?  Is
> there in inherent limitation to the server protocol that makes a request
> like this simply unworkable?
> Directories are printed with a trailing slash, so if you just want
> directories, you could grep for that:
> You already mentioned the grep solution in your message, so I’m guessing
> that’s not satisfactory for some reason. If that’s true, then maybe you
> could explain in more detail what you need exactly, if it’s not the above.
Its really a performance concern.  We need to do this fairly regularly on a
large repository (over a WAN I might add) and asking the server for all
files and directories when we really only need a directory listing is
really a huge time sink (a 100:1 file to directory ratio would result in a
listing time of 100 times slower).  Grep and the like only format the
output on the client side (which is easily parsable - we do use xml to
parse) and don't relieve the performance burden.


View raw message