On 18.06.2010 06:46, Greg Stein wrote:
On Thu, Jun 17, 2010 at 16:48, Stefan Küng<tortoise...@gmail.com> wrote:
On 17.06.2010 22:35, Bert Huijben wrote:
Sure, I said before I can get any information myself, but only with
a severe performance hit. Because every time I call an svn_client_*
API, it walks the whole tree again, opens the files again, opens
the db again and again, ...
svn_client doesn't open the db again. (The handle is cached in the
svn_client_ctx_t's wc_ctx field) and if you set a proper depth value
on your call it doesn't traverse any other nodes then the one you
specify.
But I need that information for all entries in the tree. So I have to
traverse the whole tree again.
Tree walks are expensive.
That is totally ridiculous. No. You do NOT have to walk the tree again.
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.
I don't have a problem calling another API to get additional info where i
need it only for one or just a few items. But most of the time, I need that
information for the whole tree.
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.
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.
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.
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.
Also, you make it fast by removing information returned. Meaning I have
to get that information myself. Will it still be faster then? Or will
all the additional API calls I have to make to get the same info as
before add up and make everything much slower than before? In that case,
it's not faster.
fast, then you can do that on your own side of the callbacks. All the
information is there, and a call into the APIs is no more expensive
than what our old code used to do. When it gets down to it, the SAME
function is used to do the "is modified?" check. So what the hell are
you complaining about, if you have to make the call instead of the svn
library? Not to mention, Bert saying that libsvn_client will do all
that for you, anyways, in a consistent fashion.
Stop the noise. Move along.
I'm sorry. I'm only trying to raise my concerns here.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
