svn_wc__node_*

[Greg Stein <gs...@gmail.com>]

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.

Cheers,
-g

Re: svn_wc__node_*

[Greg Stein <gs...@gmail.com>]

On Tue, Apr 27, 2010 at 09:22, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> On Tue, Apr 27, 2010 at 6:23 AM, Greg Stein <gs...@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

Re: svn_wc__node_*

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

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