On Tue, Nov 11, 2008 at 02:11:16PM +0000, Julian Foad wrote:
> These functions:
>
> svn_wc_get_tree_conflict()
> svn_wc_add_tree_conflict()
> svn_wc__del_tree_conflict()
>
> and
>
> svn_wc__loggy_add_tree_conflict()
> svn_wc__loggy_del_tree_conflict()
>
> need some "consistifying".
>
>
> * adm_access
>
> I have come up against difficulties with WC APIs that need to support
> tree conflict (TC) victims. Such victims are not always versioned and so
> do not always have the expected adm_access available. Also, the
> implementation stores TCs in the parent dir's entry, so that's the place
> we really need the baton for. Arguably it's more convenient for callers
> if they don't have to know that and can supply the victim's adm_access
> if they already have it. So we could choose either (the strict one)
>
> - "adm_access is the access baton for the parent dir of the victim.
> (If there is no versioned parent, a tree conflict cannot be
> represented.)"
>
> or (the lenient one):
>
> - "adm_access is an access baton in a set that contains an access
> baton for the parent. (If there is no versioned parent, a tree conflict
> cannot be represented.)"
>
> I'm going for the latter.
Agreed.
I hope this parent directory business will go away with wc-ng,
and be replaced by some magic mechanism that just works :)
> A "get" function could be even more lenient: if no access baton is
> supplied, get one itself. That is how it is currently implemented, and
> it can save the caller some effort. In one sense, it saves the caller
> from needing to know that the parent dir is involved, but in another
> sense it's making too many assumptions. So I think the get function
> should be as strict as the add/del functions.
What assumptions in particular are you referring to when you say
"too many assumptions"?
> * Public or private?
>
> The first three, the non-loggy ones, should all have the same level of
> publicity, or at the very least "add" and "del" should be the same.
>
> I'm going to make them all private because the very question of changing
> them today indicates that they're not stable.
I don't see a reason for this. Clients need these functions anyway, right?
Under this assumption, we'll move them back into the public API once they
are fixed anyway. So why make them private in the first place?
I thought it's OK for new public APIs to be unstable on trunk, and on
release branches until the first x.y.0 release is cut?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-11 16:16:24 CET