On Fri, Jun 18, 2010 at 01:19:18PM +0200, Stefan Küng wrote:
> On 18.06.2010 06:46, Greg Stein wrote:
> >The idea is: the status callback is invoked with the *limited* status
> >information. If you want more, then from *within* that callback, make
> >a function call back into the API to get the information you need.
> >
> >Look at that! No additional tree walks!
>
> Would work only if I'm allowed to use API's from libsvn_wc. But
> those are supposed to go away.
> In the callback, I can't use svn_client_* API's because the wc is
> locked/in-use at that time and those API's will throw an error.
The old APIs behaved like that with respect to locks.
But the new ones can be different. Sqlite will manage reader locks for us.
Any function call you make results in information being looked up in the
database, except for information that can only be found on disk.
That's my impression, anyway (someone please correct me if I'm wrong).
The idea is not to remove the functionality libsvn_wc APIs provide,
but to stop exposing the artificial barrier between libsvn_client
and libsvn_wc in the public API. Instead, new libsvn_client APIs
will provide any information you may need.
> >Great. And if you were *listening*, Bert has said we'll do that at the
> >client level. And even if we don't, then *you* can have a simple
> >callback handler that grabs the extra information.
> >
> >This is not rocket science.
>
> Since we're not dealing with rockets here, I agree.
:)
> But please understand my situation here: you're talking about
> removing APIs which I'm using extensively, and about removing the
> APIs I would need to use in the callbacks. If you make the libsvn_wc
> APIs non-public, then I can't do what you think I should do.
We want to stop exposing the WC API so we can make changes more easily.
A stable client API will be provided instead. I cannot tell you what
this API will look like (that's what Bert and Greg are trying to get
across), but I know that we won't remove functionality.
> >And as Mike pointed out: we'd not going to screw you over. So stop
> >your whining, make the extra calls in your callback, and let's move
> >on. Offer some suggestions for improvements, rather than "wah wah, I
> >don't like it".
>
> I made a perfectly fine suggestion, which got rejected only because
> it's "against Subversion policies" and my question about where such
> a policy is written down wasn't answered.
I don't know either what Bert meant (maybe something related to
binary compatibility?). It would be great to hear a better explanation.
> >Simple fact is: we're going for *fast*. If you want something less
>
> Yes, that's what I hear every time I bring something up. But making
> something fast is not the same as reducing the functionality.
Any reduction in functionality will be temporary. It simply doesn't
make any sense for us to remove functionality.
> You could speed up a status call even more if you only return one
> information: it's versioned/not versioned.
> That would be very very fast but also useless for most.
> Making something fast IMHO means making fast what's slow, not
> crippling it until nobody can use it anymore.
Again, I think this is not what the wc-ng people are doing,
and you are being offensive by repeatedly claiming that this was
the case. Please stop assuming that they want to work against you.
> Also, you make it fast by removing information returned. Meaning I
> have to get that information myself. Will it still be faster then?
Yes. Because most of it is read from an sqlite DB, rather than from
files on disk which have to be parsed in their entirety before any
information can be returned. And the information needs to be cached
to make it fast! Try disabling entries-caching in 1.6.x and you will
see a massive performance decrease (and a couple of bugs where things
only work because of stale caches...)
Peace,
Stefan
Received on 2010-06-18 14:31:01 CEST