> -----Original Message-----
> From: Stefan Küng [mailto:tortoise...@gmail.com]
> Sent: donderdag 17 juni 2010 22:28
> To: Bert Huijben
> Cc: 'C. Michael Pilato'; 'Subversion Development'
> Subject: 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, ...
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.
Subversion 1.6 did always read all the entries of a directory in memory, but
with the sqlite databases this is no longer necessary. (Unless some code
explicitly uses the old entries apis). As far as I can tell libsvn_client and
libsvn_wc don't do that from any of the not-deprecated code paths.
(A few weeks ago the code to detect a working copy root still read the names of
all nodes in the parent directory in memory, but this slowdown on extreme large
directories has been removed)
Bert
