On Tue, Apr 27, 2010 at 09:22, Hyrum K. Wright <hyrum_wri...@mail.utexas.edu> wrote: > 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_* ?
No plan yet. And I think "node" is awful in there :-P svn_wc_walk_tree (my preference) or svn_wc_walk_children. svn_wc_get_kind, or maybe svn_wc_read_kind I'd be fine with the above two calls RSN. get_kind() is very much known (lose the SHOW_HIDDEN param tho! assume TRUE; thus callers with show_hidden=FALSE need to use a private API). The walk API won't be as solid, but getting something on deck would be fine, IMO. As I said above, I think we need some kind of a walk API. I'd probably want something like walk_unversioned on it, too. Callback is probably not much more than a path, and let the callback fetch what else it wants. Cheers, -g
