On 10/22/05, philipp.marek@bmlv.gv.at <philipp.marek@bmlv.gv.at> wrote:
> 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.
Like I said in my reply to Peter's email, I haven't looked into it too
closely, but if there are similar situations where the calculation of
unused dirent data is presenting a noticable speed problem to the user
I'd certainly be in favor of it.
> And my three wishes:
>
> 1) Please include MD5 and svn:special as flags.
Well, neither the MD5 or the svn:special value are part of the dirent,
so controlling the retrieval of that information really isn't part of
this particular proposal. Not saying that we shouldn't do it, just
that it isn't the problem I'm looking to solve right now.
> 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.
This is similar to the kind of thing the underlying ra_dav code does
to determine what data to get from the server for a PROPFIND request.
I'll think about what would be required to add that kind of interface
here, and who knows, maybe it can provide us with some similar
performance gains, but I'm not sure where they would be off the top of
my head. Some more research is probably required on this topic.
> 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.
Again, this is interesting stuff, and if you have a proposal for how
such an API would look and how it would be implemented under the hood
I'd be happy to take a look at it, but it really isn't the problem I'm
trying to solve right now. I'm also not clear that encoding such
intimate details of how svn:special is used at this level of the API
is a good idea.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 24 08:35:07 2005