[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: status information

From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 16 Jun 2010 21:40:42 +0200

> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
> Sent: woensdag 16 juni 2010 21:29
> To: Subversion Development
> Subject: status information
>
> Hi,
>
> Since the svn_wc_status3_t struct is now missing the entry member, a
> lot
> of information previously available from a status call is missing.
> I can work around a lot of that information using other svn API calls,
> but there's at least two pieces of info I'd really have back in a
> status
> call:
>
> working size : the size of the files returned by 'svn st'. Since a
> status call has to stat the files anyway, that information shouldn't be
> expensive to get.
>
> svn:needs-lock : I know this is a property and hasn't really anything
> to
> do with the status of items. But it's a very important piece of
> information. In TSVN, we use this to show a special overlay icon so
> users can immediately see that they have to get a lock before trying to
> edit the file. The 'readonly' flag on such files isn't of much help
> here
> since most apps don't warn users about it until they try to save their
> changes.
> If it's too expensive to get the info whether the property is set,
> having the info whether the readonly filesystem flag is set would also
> work, and that info could be fetched with the file stat call that I
> think has to be done anyway.
>
> Please consider adding these info pieces to the svn_wc_status3_t
> struct.

The plan is to remove even more expensive members from svn_wc_status3_t, to
make it just return cheap information. (I think working_size is available,
so we can add that specific one; but the scan if the file has been modified
on disk will be removed).

The plan is to introduce a new svn_client_status_t structure (for
svn_client_status) which will have more data then the svn_wc_status3_t
structure, but we haven't started on that one.

The assumption here is that users of the libsvn_wc api want direct access to
the working copy without any performance penalties they might not want.
(E.g. not scanning the file for changes, or parsing all the conflict
details)

On the other side: users of the libsvn_client api wants to have access to
the direct usable combination of data, which might give less performance.

        Bert
Received on 2010-06-16 21:41:34 CEST

This is an archived mail posted to the Subversion Dev mailing list.