[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: branch tc_url_rev: almost ready to merge

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 25 Nov 2008 12:21:31 +0100

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?


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.