Hi!
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
caller.
* 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
versioned.
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
svn_wc_status_kind).
Cheers,
Daniel
Received on 2010-05-12 15:10:52 CEST