On Wed, May 12, 2010 at 3:10 PM, Daniel Näslund <daniel_at_longitudo.com> wrote:
> 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.
Or you can just read it with _read_info() with all other information
> * 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?
I would keep these working, or replace them with a similar wc-ng
status, but keep the status if we also see a conflict or other high
priority status. (In status2_t you loose status_modified if you have a
conflict)
You call status to see if a node is locally modified, so you need this
info in one format or another
> * 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.
If we have it for free we can just pass it to users. (I know it is
used by many clients).
You need the url of a node and its parent to determine if a node is
switched, so I would keep both in the structure.
(In AnkhSVN I'm really not that interested in switched.. I just want
to know if a node is commit/diff/revertable.)
You should also add a node kind to the status structure. (Status
without node kind requires looking at disk).
And probably depth too as you often need that to process the result.
(And you have both available anyway)
Bert
> * 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 19:05:44 CEST