On Tue, Apr 27, 2010 at 6:23 AM, Greg Stein <gstein_at_gmail.com> wrote:
> count-progress.py is reporting 143 uses of svn_wc__node_* in my
> working copy. A quick breakdown of these calls results in:
>
> 8 node_get_base_rev
> 9 node_get_changed_info
> 1 node_get_changelist
> 5 node_get_children
> 2 node_get_commit_base_rev
> 6 node_get_copyfrom_info
> 2 node_get_depth
> 33 node_get_kind
> 2 node_get_lock_token
> 10 node_get_repos_info
> 23 node_get_url
> 7 node_is_added
> 3 node_is_file_external
> 1 node_is_replaced
> 1 node_is_status_absent
> 9 node_is_status_deleted
> 3 node_is_status_obstructed
> 1 node_is_status_present
> 12 node_walk_children
>
> We are 14 entry_t uses away from "done" in libsvn_client. That means
> the above calls are pretty close to the end-result.
>
> The get_kind is quite believable, and should probably move to our
> public API. Seems quite reasonable, along with Neels' changes to
> create better consistency in its outputs.
>
> The get_url concerns me a bit, since most states of a node don't
> actually have a URL. They may have an *intended* URL after a commit.
> I'm somewhat worried those get_url calls are mis-using or do not
> properly understand the "this node doesn't have a URL" concept.
> get_repos_info kind of falls into this area, too.
>
> The walk_children is pretty obvious, and I definitely think we should
> have such an API in our public header. In particular, provide that API
> to users rather than specialized walk/editor mechanisms, and let
> callers request the specific information they need.
>
Thanks for the analysis. When we do move these APIs to the public space,
what's the plan for naming them? svn_wc_node_* ?
-Hyrum
Received on 2010-04-27 15:23:14 CEST