Re: request to make svn_wc__prop_list_recursive a public API

On 17.02.2011 13:39, Julian Foad wrote:
> On Thu, 2011-02-17, Stefan Sperling wrote:
>> On Thu, Feb 17, 2011 at 12:47:32PM +0100, 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 would prefer not to expose the WC API directly.
>> I think that was a mistake, because it complicated the wc-ng effort
>> since it had to cater to consumers of these APIs.
>>
>> We should make sure that the libsvn_client API provides sufficient
>> access to the WC layer without exposing implementation details.
>>
>> If setting up a client context is too much overhead, then maybe
>> we should try to address that problem, instead of ignoring it
>> and making all the WC APIs public again.
>
> Hi, Stefan Küng. It was good to talk to you the other day. Thanks for
> being brave enough to speak up and request something again!
>
> I was about to say +1 to making that API public - based on the idea that
> if any WC functions are public then logically this one should be - but
> Stefan's mail reminded me that maybe this is a good time to see if we
> can make a better libsvn_client API instead. If we can't, and it's
> actually causing you a problem, then I think we should support this as a
> public WC API.
>
> Let me point out the background, in case you weren't aware. There has
> been a general feeling (especially during the WC re-write) that the WC
> API wasn't well suited to being maintained as a public API and that we
> should move in the direction of providing a better client-layer public
> API instead.
>
> It looks like we're running in to the issue of the current client API
> design not being very suitable for GUI clients. In some cases the
> problems are clear and obvious (such as when you need to perform
> multiple repository operations but cannot re-use the network
> connection), but in this case I'm not sure what the main problem is.
>
> Can we dig a little into the specifics of this case please to try to
> understand it better? Is it to do with managing the lifetime of the
> client context object?
>
> Also we (core Subversion devs) should try to figure out what it is about
> the WC APIs that was not very maintainable, and maybe see if we can keep
> a public subset that is maintainable. After all, there are advantages
> to keeping a separation between libraries, if we do it well.

As I mentioned, it's not a big deal for me. I can use the
svn_client_proplist3() API instead. It just would be easier for me to
use the now private API since we already use the svn_wc_prop_list2() API
and so I just could use the initialization code we already have for that.

And since there already *is* a svn_wc_prop_list2 API I figured that it
would be consistent to also have that same API which does the recursive
work.

But I'm now almost finished changing the code in TSVN to use the
svn_client_proplist3() API instead of the svn_wc_prop_list2() so it's
not a problem for me anymore.

Of course I still think a new svn_wc_prop_list3() API is neccessary, at
least to be consistent.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net