You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2011/02/17 12:47:32 UTC
request to make svn_wc__prop_list_recursive a public API
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?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: request to make svn_wc__prop_list_recursive a public API
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/18/2011 09:23 AM, Stefan Küng wrote:
> I wanted to avoid this, but if you remember we've had this discussion
> before. I requested that the new status API would return information that
> the deprecated one did too. And the very first answer I got was that even
> "the scan if the file has been modified on disk will be removed".
> I first thought this was a joke, because status means (for me at least) the
> information whether a file has been modified/added/... locally - but
> apparently it wasn't. So the discussion just went downhill from there:
> http://thread.gmane.org/gmane.comp.version-control.subversion.devel/120475/focus=120550
>
> warning: that discussion is something I'm not proud of, and I think some of
> you aren't either.
Oh, I recall this discussion well, and you're right: it's not something to
be proud of.
As you continue to make your requests, please try to keep in mind that
there's not a single person here that can speak for the whole project. As
has been the case for the past eleven years, what is and what isn't are
defined by actual work being done -- and running our mouths on a mailing
list doesn't count as work! :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Stefan Küng <to...@gmail.com>.
On 18.02.2011 14:37, C. Michael Pilato wrote:
> On 02/18/2011 06:42 AM, Stefan Küng wrote:
>> On 17.02.2011 14:19, Hyrum K Wright wrote:
>>
>>> <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>
>>
>> Removing all the libsvn_wc APIs is a bad idea. For example, the new status
>> function returns a *lot* less information than the deprecated ones.
>
> Stop right here. There seems to be an assumption clouding this discussion,
> and that assumption is that "the new status function" is the only new status
> function that can be added. It's our API -- your API -- and we can do with
> it what we wish. If you need the functionality of some current libsvn_wc
> function, chances are that you're not the only one who does. Fortunately,
> we are both empowered and motivated to provide that functionality to you
> wrapped with a thin svn_client wrapper function. Is there some technical
> reason that would prevent this?
>
I wanted to avoid this, but if you remember we've had this discussion
before. I requested that the new status API would return information
that the deprecated one did too. And the very first answer I got was
that even "the scan if the file has been modified on disk will be removed".
I first thought this was a joke, because status means (for me at least)
the information whether a file has been modified/added/... locally - but
apparently it wasn't. So the discussion just went downhill from there:
http://thread.gmane.org/gmane.comp.version-control.subversion.devel/120475/focus=120550
warning: that discussion is something I'm not proud of, and I think some
of you aren't either.
So all I'm saying is that you can decide whatever you want. I will keep
requesting things I need, but I'm trying to avoid discussions like the
one linked above. And as I said: you have to decide whether you want to
mark all functions in libsvn_wc as private or provide enough information
in *one* svn_client_ call. Otherwise the performance will get so bad it
will be unusable.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: request to make svn_wc__prop_list_recursive a public API
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/18/2011 06:42 AM, Stefan Küng wrote:
> On 17.02.2011 14:19, Hyrum K Wright wrote:
>
>> <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>
>
> Removing all the libsvn_wc APIs is a bad idea. For example, the new status
> function returns a *lot* less information than the deprecated ones.
Stop right here. There seems to be an assumption clouding this discussion,
and that assumption is that "the new status function" is the only new status
function that can be added. It's our API -- your API -- and we can do with
it what we wish. If you need the functionality of some current libsvn_wc
function, chances are that you're not the only one who does. Fortunately,
we are both empowered and motivated to provide that functionality to you
wrapped with a thin svn_client wrapper function. Is there some technical
reason that would prevent this?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Feb 18, 2011 at 12:42:30PM +0100, Stefan Küng wrote:
> On 17.02.2011 14:19, Hyrum K Wright wrote:
>
> ><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>
>
> Removing all the libsvn_wc APIs is a bad idea. For example, the new
> status function returns a *lot* less information than the deprecated
> ones. The only way to get that information back now without a *huge*
> performance loss is to use those APIs in the status callback.
> Without those, fetching the missing information requires accessing
> the disk over and over again using different svn_client_ APIs.
That situation is really bad and needs to be fixed.
But it's a separate issue. There is no question that we want to
provide the best possible API. We just haven't decided yet whether
to put it in libsvn_client or libsvn_wc. It sounds like you don't
have a preference either way as long as you can efficiently get at
the information you need?
> So either you have to provide as much information as possible in
> e.g. svn_client_status or not remove the libsvn_wc APIs. You can't
> do both remove information and remove the APIs if you want to keep
> svn clients useful and fast.
Keep in mind that the 1.7.x APIs you're looking at are work-in-progress.
Your input will help the community decide how to proceed.
I think we should gather your requirements in detail and file a set of
issues based on them. If you have the time, could you point out, in detail,
the differences you see between the 1.6.x and 1.7.x API that cause problems
for TortoiseSVN? So that they can be addressed before release?
And of course, feel free to help with fixing the problems directly
using your commit bit :)
Thanks,
Stefan
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Stefan Küng <to...@gmail.com>.
On 17.02.2011 14:19, Hyrum K Wright wrote:
> <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>
Removing all the libsvn_wc APIs is a bad idea. For example, the new
status function returns a *lot* less information than the deprecated
ones. The only way to get that information back now without a *huge*
performance loss is to use those APIs in the status callback. Without
those, fetching the missing information requires accessing the disk over
and over again using different svn_client_ APIs.
So either you have to provide as much information as possible in e.g.
svn_client_status or not remove the libsvn_wc APIs. You can't do both
remove information and remove the APIs if you want to keep svn clients
useful and fast.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: request to make svn_wc__prop_list_recursive a public API
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/17/2011 08:19 AM, Hyrum K Wright wrote:
> 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>
Perhaps you need to stop thinking of TortoiseSVN as "outside of Subversion".
We should be able to provide useful, public *libsvn_client* APIs that
aren't solely consumed -- or consumed at all -- by the command-line client.
libsvn_client wasn't designed to be used only by 'svn'.
I concede that this mass deprecation would leave the svn_wc interface in
limbo. But I also don't care, because I would bet dimes to dollars that
*nobody* is using that API for something other than Subversion version
control. Therefore, it's perfectly okay in my book to deprecate a svn_wc
function with a pointer to its replacement in svn_client.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
2011/2/17 Branko Čibej <br...@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
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Branko Čibej <br...@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.
-- Brane
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Stefan Küng <to...@gmail.com>.
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
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Feb 17, 2011 at 02:17:16PM +0100, Branko Čibej wrote:
> With a sane, useful public WC API you can at least think about plugging
> different WC backends ... someday. Same goes for the repos/fs separation.
I'd say doing this now is premature optimisation.
Especially because wc-ng isn't done yet and we can expect new APIs
to appear or existing APIs to change, even during the 1.7->1.8 cycle.
When someone comes along and writes a new backend (which is possible since
the layers are still cleanly separated even though the API is private),
and that backend is likely to be maintained separately so it needs
a stable API, then we can do it. Before then, I see little point in
the churn involved in reving WC APIs whenever we find a mistake in them.
At the backend, separate implementations already exist (fsfs, bdb,
bigtable), one of which is maintained by a third party.
So maintaining the existing public API there is worth it.
And how can we know that the public API we design now is suitable for new
kinds of WC backends people would want to write, until such a backend exists?
Google ran into problems with assumptions the FS API was making and
had to work around them: http://svn.haxx.se/dev/archive-2010-03/0735.shtml
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Greg Stein <gs...@gmail.com>.
I concur with all of Mike's statements here. I see no reason to
believe that we'll *ever* see any intention of pluggable working copy
libraries.
On Thu, Feb 17, 2011 at 09:22, C. Michael Pilato <cm...@collab.net> wrote:
> On 02/17/2011 08:17 AM, Branko Čibej wrote:
>> On 17.02.2011 14:12, Stefan Sperling wrote:
>>> On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
>>>> On 17.02.2011 13:39, Julian Foad wrote:
>>>>> 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.
>
> +`wc -c subversion/include/svn_wc.h | cut -d ' ' -f 1`!
>
> I'm one of those folks who thinks the client/wc distinction was foolhardy.
> I've come around to being alright with the modularization we have today with
> the two libraries. But I strongly believe that there should never have been
> a *public* svn_wc.h, and that what lives there now should never, ever be
> revised again save for mass deprecation.
>
>> s/client/repos/g
>> s/WC/fs/g
>> s/working copy/versioned filesystem/g
>> repeat
>
> This isn't a fair comparision. The FS API does something completely
> meaningful, independent of the larger Subversion version control system.
> Actually, depending on how you look at it, it could be said that the FS API
> and library *are* Subversion. Everything else is just tooling to help
> mortals use the FS.
>
>> With a sane, useful public WC API you can at least think about plugging
>> different WC backends ... someday. Same goes for the repos/fs separation.
>
> We have no reason to believe that anyone would want to write a new WC
> storage layer, but that's not so important. I see two other matters that
> are, though.
>
> First, it's not the lack of a *public* WC API that would be a blocker to
> implementing a new WC storage layer. The lack of a WC API, sure, but it's
> publicity is disinteresting.
>
> Secondly, it's *extremely* unlikely that someone would want to use the
> Subversion WC library independently of Subversion itself. Using the terms
> you have above, there's independent value in having a "versioned
> filesystem"; not so much in a "working copy".
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
Re: request to make svn_wc__prop_list_recursive a public API
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 02/17/2011 08:17 AM, Branko Čibej wrote:
> On 17.02.2011 14:12, Stefan Sperling wrote:
>> On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
>>> On 17.02.2011 13:39, Julian Foad wrote:
>>>> 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.
+`wc -c subversion/include/svn_wc.h | cut -d ' ' -f 1`!
I'm one of those folks who thinks the client/wc distinction was foolhardy.
I've come around to being alright with the modularization we have today with
the two libraries. But I strongly believe that there should never have been
a *public* svn_wc.h, and that what lives there now should never, ever be
revised again save for mass deprecation.
> s/client/repos/g
> s/WC/fs/g
> s/working copy/versioned filesystem/g
> repeat
This isn't a fair comparision. The FS API does something completely
meaningful, independent of the larger Subversion version control system.
Actually, depending on how you look at it, it could be said that the FS API
and library *are* Subversion. Everything else is just tooling to help
mortals use the FS.
> With a sane, useful public WC API you can at least think about plugging
> different WC backends ... someday. Same goes for the repos/fs separation.
We have no reason to believe that anyone would want to write a new WC
storage layer, but that's not so important. I see two other matters that
are, though.
First, it's not the lack of a *public* WC API that would be a blocker to
implementing a new WC storage layer. The lack of a WC API, sure, but it's
publicity is disinteresting.
Secondly, it's *extremely* unlikely that someone would want to use the
Subversion WC library independently of Subversion itself. Using the terms
you have above, there's independent value in having a "versioned
filesystem"; not so much in a "working copy".
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Branko Čibej <br...@e-reka.si>.
On 17.02.2011 14:12, Stefan Sperling wrote:
> On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
>> On 17.02.2011 13:39, Julian Foad wrote:
>>> 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.
>> I think going that way would be a terrible mistake. By all means make
>> the WC API useful on its own.
> What's the benefit to API consumers?
>
> An internal client/WC separation makes sense because code is layered
> cleanly. But to the outside the entire client lib is already a black box
> that can contact a repository and also modify a working copy.
>
> Why have another, smaller, black box sitting next to it that can only
> perform a subset of the same tasks? If I wrote a program against these
> APIs today I wouldn't readily know which one to use when.
s/client/repos/g
s/WC/fs/g
s/working copy/versioned filesystem/g
repeat
:)
With a sane, useful public WC API you can at least think about plugging
different WC backends ... someday. Same goes for the repos/fs separation.
-- Brane
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
> On 17.02.2011 13:39, Julian Foad wrote:
> > 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.
>
> I think going that way would be a terrible mistake. By all means make
> the WC API useful on its own.
What's the benefit to API consumers?
An internal client/WC separation makes sense because code is layered
cleanly. But to the outside the entire client lib is already a black box
that can contact a repository and also modify a working copy.
Why have another, smaller, black box sitting next to it that can only
perform a subset of the same tasks? If I wrote a program against these
APIs today I wouldn't readily know which one to use when.
And the less public functions we have, the more agile we can be when
changing internals of libsvn_client and libsvn_wc. So for us, the
benefit of keeping the wc API private is huge, while there's not much
benefit for API consumers if we make it public.
Of course, this implies adding new public API functions at the client
layer if there are things clients want to do that they cannot do
with the current client APIs.
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Branko Čibej <br...@e-reka.si>.
On 17.02.2011 13:39, Julian Foad wrote:
> 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.
I think going that way would be a terrible mistake. By all means make
the WC API useful on its own.
-- Brane
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Julian Foad <ju...@wandisco.com>.
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
Re: request to make svn_wc__prop_list_recursive a public API
Posted by Stefan Sperling <st...@elego.de>.
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.