David Glasser wrote:
> Wait, we're documenting svn_wc__something as something third-party
> developers should use and rely on???
Negative. We're documenting it as something only to be used
intra-library within core Subversion.
Let me try to explain what we are trying to do.
We are helping third-party developers to experiment with some non-public
guts of Subversion 1.6. The example code which is called "svnraisetc"
effectively shows how to build a modified Subversion that exposes a
public interface to this API. The example tool is not for end users, and
it is tied to one particular source code release and not subject to our
forward compatibility guarantees.
This is like one developer helping another: "Here, if you want to
experiment with using Subversion's guts, try this... And if you like it,
you could help us to stabilize it and make it public."
Is there a part of that scenario that is wrong for the project, or are
we just using the wrong labels or something?
Let's say we name the example code
/contrib/dev/svn-1.6.0-raisetc-example.c
I hope that will make its status clearer.
Justin Erenkrantz wrote:
> The function needs to be in the public API if anything outside of
> libsvn_wc invokes it. -- justin
Negative. We have non-public intra-library within-Subversion APIs. See
<hacking.html>. Or did you mean there's something special about this
particular function, or that we shouldn't allow ourselves this
flexibility in this case? If so, why?
Stefan Sperling wrote:
> Neels Janosch Hofmeyr wrote:
> > are we fine with making svn_wc__add_tree_conflict() public for the sake of
> > the svnraisetreeconflict commandline tool?
>
> There's already good use for it, so I don't see why not.
[...]
> >Having this public also means having to support it at least until 2.0.
> >Shouldn't be too hard.
Take a look at the doc string:
[[[
/** Record the tree conflict described by @a conflict in the WC.
* @a adm_access must be a write-access baton for the parent directory of
* @a victim->path. Use @a pool for all allocations.
*
* Warning: This function updates the entry on disk but not the cached entry
* in @a adm_access.
*
* @since New in 1.6.
*/
svn_error_t *
svn_wc__add_tree_conflict(const svn_wc_conflict_description_t *conflict,
svn_wc_adm_access_t *adm_access,
apr_pool_t *pool);
]]]
Straight off, two things I don't want public: what that warning is
about, and the fact that "adm_access" is for the parent dir and not the
entry's own dir (though the latter sounds straightforward to support in
the future).
Not so obviously, this API doesn't really specify how much of the
"conflict" data structure is relevant and required.
Now, apart from that thing about not updating the cached entry, this
stuff is maybe not a big deal. It's perhaps no looser than some other
APIs that we support. So we could do it. I'm just saying that we can't
take for granted that the API is a good one to expose.
If we were to insist on making it public, I think we would have to fix
that cache thing, which would be great in itself but I don't think we
really need to invest that effort right now.
> > Answering `yes' here suggests that ...__remove_tree_conflict() and such
> > should also go public.
>
> I'm not sure people would really want to remove conflict markers
> in other ways than using 'svn resolve' or the equivalent command
> in their GUI. At least I have not heard of such use.
I don't know. Certainly the "resolve" API can come quite close to doing
just a "remove tree conflict from the WC", so it's not so important to
make it public, but it doesn't seem logical to keep it private if "add"
is public. Either way, it's not a big factor in this discussion.
> And what's "and such"?
svn_wc__get_tree_conflict(), I should think, although, like with "del",
there are alternative ways to access this functionality ("status" or
"info", I think).
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1013869
Received on 2009-01-09 16:01:56 CET