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.
- Julian
Received on 2011-02-17 13:40:20 CET