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

What are the plans for svn_wc_status3_t?

From: Daniel Näslund <daniel_at_longitudo.com>
Date: Wed, 12 May 2010 15:10:15 +0200


I set out to remove the entry field in svn_wc_status3_t. The reasons was
i) svn_wc_entry_t is deprecated and ii) fetching all the info contained
in the entry field is slow and we want 'svn status' to be fast!

So far this has been done:
* The revision information has been moved out to its own fields. The
  idea is that those fields should be clearly defined, contrary to the
  entry ones.
* entry->changelist information is fetched with a node func in the
* Added a field, status->conflicted. The caller is supposed to find out
  what conflict it is.
* Added a field status->versioned. The caller can use this one instead
  of the presence of status->entry for determining if a path is

What are the plans for...
* status->text_status. Should it be replaced with a boolean indicating
  if there are text modifications?
* status->prop_status. Should it be replaced with a boolean indicating
  if there are props modifications?
* status->copied. It could be a bit expensive to calculate but only
  returning status_added and have the API user determine if it's copied
  feels like a leaky abstraction to me. My take is that all API users
  wants to know if the node is copied.
* status->switched. Everyone probably wants to know that too. We need
  the url's to determine if the node is switched which brings me to...
* status->url. It is not used in svn/status{,-cmd}.c. How many other
  callers use it? If we keep status->switched, we still have to fetch
  the url though.
* svn_wc_status_kind. Should it be revved to map to
  svn_wc__db_status_kind_t in some other way. We've already made the
  svn_wc_status_conflicted alternative obsolute (atleast for
  svn_wc_status3_t. I haven't checked the other uses of

Received on 2010-05-12 15:10:52 CEST

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