Re: WC-1 adm_access batons - necessary for reading? [was: svn commit: r33726]

[Julian Foad <ju...@btopenworld.com>]

On Mon, 2008-10-20 at 10:02 +0100, Julian Foad wrote:
> sbutler@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@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>