On Tue, Apr 27, 2010 at 6:23 AM, Greg Stein <gst...@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
