Re: status information

On 17.06.2010 22:08, Bert Huijben wrote:

>> May I suggest an approach that doesn't force me to find expensive
>> workarounds for more and more missing information the svn APIs
>> return: Use a mask parameter which specifies which members of a
>> returned struct get filled in by the API and which ones are not.
>> That way, the less one specifies in the mask the faster the API
>> returns, but if necessary everything necessary can still be
>> returned in one tree walk without the need to invoke several other
>> APIs which also do the very same tree walk.
>>
>> If you need an example, have a look at TVM_GETITEM and the
>> TVITEMEX struct:
>> http://msdn.microsoft.com/en-us/library/bb773758%28v=VS.85%29.aspx
>> http://msdn.microsoft.com/en-us/library/bb773459%28v=VS.85%29.aspx
>> The mask member specifies which members of the struct will be
>> filled by the TVM_GETITEM call.
>>
>> This also has the advantage that new data can be added later
>> without changing the API.
>
> Using flags for this is against the subversion principles, so this
> would require adding booleans to svn_client_statusX() for every flag
> on what you want and don't want.

Where's this policy in writing?
Using booleans is good as long as there are only few. If more are
needed, then a mask is the much better option.
And I think policies have to change if sticking to them would mean
serious drawbacks.

> For WC-NG we used a similar approach, but it only works when you are
> calling an API: allow output arguments to be NULL. But this requires
> that you are calling the api from the callback. (Which was exactly
> the plan for every expensive operation; especially if you can't say
> which value you want for which file/directory)

But calling an API from a callback either means using API's from
sub-libraries (like libsvn_wc), or getting a huge performance hit by
using svn_client_ API's.

> But before continuing this conversation, can you check if
> svn_client_status_t (in svn_client.h) contains what you need?

As I said before, I'd like the svn:needs-lock and the size param back.

> I think we can safely remove the locked boolean from this struct
> (which requires an additional DB lookup per directory) and you asked
> for the translated filesize.
>
> (Not sure if the filesize that is still a useful addition for every
> result as you can obtain such values very cheap via different APIs
> now, because we don't have to read all entries at once any more. And
> I don't think you use that value while walking the status, but only
> after it returned)

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, ...

I'm currently facing big problems because of this. The svn lib is much
slower on trunk as it is (yes, it should improve soon, but we'll have to
first see how much it will improve). And you guys removing more and more
information I need and rely on from APIs means I have to either add more
and more expensive API calls or drop whole features.
For the missing svn:needs-lock, I did some testing and the performance
hit is so severe that I have to drop several features in TSVN because of
this.
So for me, 1.7 doesn't look like an improvement at all, no matter how
great WC-NG will get. There aren't any new features in it (yet) which I
haven't already used in 1.6, but I have to drop more and more existing
features.

And from your comments I get the impression that it will get worse (for
me and TSVN) as time goes by.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net