On Tue, Nov 25, 2008 at 06:52:44AM +0100, Neels J Hofmeyr wrote:
> >> + /* Remember to update svn_wc__conflict_version_dup()
> >> + * in case you add fields to this struct. */
> >> +} svn_wc_conflict_version_t;
> >
> > The structure's alloc and dup functions should be here.
> >
> > Consider: Would it make sense for this struct be a private definition,
> > even though it appears within a public structure?
>
> I think not. It's just making things very annoying. We'd have to change use
> of svn_wc_conflict_description_create_tree() to not take pointer arguments
> of this struct. Making them public in r34400.
Then why not just make svn_wc_conflict_description_create_* private as well?
I remember some people saying that making the working copy library
part of public API was a mistake, and that we should push 3rd party
clients to using libsvn_client exclusively. While this may not be
entirely realistic at this point, why add more public API to libsvn_wc,
especially for API which is only used by libsvn_wc itself and
libsvn_client to create conflict descriptors?
Are there clients out there that want to flag conflicts themselves,
bypassing what our libraries are already doing for them?
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-25 12:22:06 CET