sbutler_at_tigris.org wrote:
> Remove a useless extra arg to svn_wc_get_tree_conflict(), which I added
> in r33620.
>
> * subversion/include/svn_wc.h
> (svn_wc_get_tree_conflict): Remove boolean arg adm_access_is_parent.
[...]
> svn_wc_get_tree_conflict(svn_wc_conflict_description_t **tree_conflict,
> const char *victim_path,
> svn_wc_adm_access_t *adm_access,
> - svn_boolean_t adm_access_is_parent,
> apr_pool_t *pool);
(Steve, thanks - that makes the API much cleaner.)
Hey, WC-1 gurus...
I wondered if we can go one step further: a read-only API like this
hardly needs an adm access baton to be supplied. It can get one
internally if it needs one internally (which it does - but for the
target's parent, which is not the target's adm area if the target is a
directory). If so, we can delete the "adm_access" argument from this
API.
Is that valid? From what I see of the svn_wc_adm_open...() functions, it
might not be valid if the caller presently has the directory locked for
write. Then if this function internally tries to get a read baton
(without having any existing baton to refer to), it will be denied.
I'm under the impression that the canonical way to refer to a WC node in
a call to any WC function is (path, adm_access). Though there are a few
APIs that aren't like that, does that sound about right? If so,
obviously the "adm_access" parameter should stay.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-20 12:15:36 CEST