On Tue, 2008-11-11 at 15:15 +0000, Stefan Sperling wrote:
> 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"?
Er... sorry, can't think straight about this right now.
> > * 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?
I don't quite follow you. You don't agree they are unstable, or you
think it's OK to branch for release while they are unstable?
Clients generally use the libsvn_client functions, not these WC
functions. There is not necessarily any need for any client to see these
functions.
If you mean libsvn_client, then it can still see them (I mean they
should be private across Subversion core code, not hidden inside
libsvn_wc.)
> 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'm thinking in terms of the "fixes" that we will make over the next 6
months, not those in the next few days.
> 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?
There are two ways to make an API stable. Use it, test it, and become
comfortable that it is right, or promise that it will be stable from now
on and then do whatever is necessary to support it the way it is, even
if that turns out to be poor and supporting it restricts further
development.
I don't like the idea of promising to support these, when there don't
seem to be any significant benefits to doing so. Mark agreed.
- 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-11-13 15:08:34 CET