On Tue, 2008-11-25 at 17:07 +0100, Stephen Butler wrote:
> > I get a bit muddled about public/private considerations. I argued that
> > the add/del/get-tree-conflict functions should be private to Subversion.
> > Now we are adding tree conflict data to this structure that is already
> > public, and we are considering whether to keep its alloc and dup
> > functions private. I think the answer here is that that alloc and dup
> > functions are "part of" the proper semantic definition of a data
> > structure. Note that C++ requires[1] an alloc function ("constructor")
> > and a dup ("copy constructor") for every class. The semantics and
> > backward-compatibility issues of these functions are simple, so there
> > should be no problem with making them public. A client might want to
> > keep copies of these structures outside the pool that we provide them
> > in, so there is a need for them to be public.
> >
> > Neels made them public in the branch.
> I was talking yesterday with Nico Schellingerhout, creator of the
> trumerge tool for tree conflict handling in Subversion 1.4, and BTW a
> customer of ours (elego's). He suggests that a new version of
> trumerge for svn 1.6 could look for cases that we don't yet catch
> (such as use case 5) and use the working copy library to set new
> tree conflicts.
>
> Is it possible for a third-party tool to create a new tree conflict?
Yes, if built against our source code. Such a tool can use any of the
project-scope APIs including those in
"subversion/include/private/svn_wc_private.h", which is where
svn_wc__add_tree_conflict() is. I think that is the only API necessary
to raise a tree conflict.
To make the API accessible at link time, we could make it public.
I'll have a look and see if I can see more accurately what is possible.
Certainly I had not been expecting third-party tools to try to raise
tree conflicts, so haven't had this in mind as a requirement.
- 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-25 17:36:28 CET