Re: status information

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