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
Received on 2011-02-18 13:13:20 CET