[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 20 Oct 2008 10:02:39 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.