On Mon, 2008-10-20 at 10:02 +0100, Julian Foad wrote:
> 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'm attaching my patch that shows what I'm trying to do here.
- Julian
> 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
>
---------------------------------------------------------------------
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 20:48:03 CEST