[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: an idea for making 'svn list' faster

From: <philipp.marek_at_bmlv.gv.at>
Date: 2005-10-22 19:36:56 CEST

Garrett Rooney wrote:
> I'm looking at ways to make 'svn list' faster. Specifically, it seems
> quite odd to that running 'svn list' on a large directory full of tags
> takes far far longer than viewing that directory via mod_dav_svn.
> #define SVN_DIRENT_FIELD_KIND = 0x00001;
> #define SVN_DIRENT_FIELD_SIZE = 0x00002;
> #define SVN_DIRENT_FIELD_HAS_PROPS = 0X00004;
> #define SVN_DIRENT_FIELD_TIME = 0X00016;
> Any thoughts?
While you're on the track, I'd like to post three wishes and a suggestion.

The suggestion first. How about combining this interface with do_status? The
purposes look very much the same to me.

And my three wishes:

1) Please include MD5 and svn:special as flags.

2) Or, better yet, make a parameter of
       char *properties[]; // NULL-terminated
to request the properties needed. The entries would include a
       svn_string_t *property_values[];
with the same order as requested.
Then MD5, svn:special, and others like svn:unix-mode (:-) could be retrieved
directly, without any more round-trips.

3) Please, please, *please* give me a way to get the text of svn:special files.
(Or, maybe easier, add another parameter with the meaning 'give text of all
files smaller than x bytes' - 0 means no text).
I'd very much like to get rid of many, many, too many roundtrips ... one for
each symlink (and other special entries - but that's specific to fsvs).
I believe that knowing where the symlinks point to is not uninteresting for you,
too ...
Although that would possibly mean a more do_status-like interface.

Thank you very much for your efforts!



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 22 19:38:46 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.