On 18.06.2010 14:30, Stefan Sperling wrote:
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.
So as I said, what was suggested before simply can't be done in the
current state. Thanks for finally getting a reasonable answer to my
repeated complaints.
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.
So again, I mentioned that I'm missing information which I can't get
without severe performance hits. And I get smashed because of my concerns.
You're the first one to tell me that there will be new APIs that will
allow me to do sometime later what I was yelled at to do now.
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.
Agreed. And I still think it would be good to have such a 'mask'
parameter and have the svn lib do all the work: this prevents having all
clients do the same work in (most likely) different ways and therefore
get inconsistent behavior over the different clients.
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.
I better not comment on that...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
