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

Re: request to make svn_wc__prop_list_recursive a public API

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Thu, 17 Feb 2011 13:19:25 +0000

2011/2/17 Branko Čibej <brane_at_e-reka.si>:
> On 17.02.2011 12:47, Stefan Küng wrote:
>> Hi,
>>
>> The new function svn_wc__prop_list_recursive() provides a big
>> performance gain for listing all properties of a full working copy.
>> Currently I have to use svn_client_proplist3() to make use of that.
>>
>> But I'd like to have that API accessible directly, the same way e.g.
>> svn_wc_prop_list2(). It is much easier to use those APIs for accessing
>> the working copy because then I don't have to set up a full client
>> context.
>>
>> Of course if you like to keep that API private, I'm ok with that too
>> since I can use the svn_client_ API instead if I have to.
>>
>> Thoughts?
>
> I think svn_wc_prop_list2 should be rev'd to *3 and given a depth
> parameter, and call proplist_recursive, because the latter can handle
> depth=empty, too. It should be possible to reimplement other public and
> not-so-public prop-reading functions as wrappers for the _recursive case.

Without having looked at that code recently, I think this is the right
strategy. If the APIs are useful outside of Subversion, let's expose
'em publicly, instead of making those consumers feel like second-class
citizens.

<aside>
Last summer in Berlin we had a quite heated discussion about just
deprecating all of libsvn_wc APIs. I was against such a move (at
least until 2.0) in that it would leave the existing APIs public, but
any new ones private, and the whole interface in limbo. I still feel
that way, and this discussion vindicates that feeling (at least to me
:) ).
</aside>

-Hyrum
Received on 2011-02-17 14:20:04 CET

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.