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

Re: svn commit: r1309283 - in /subversion/trunk/subversion: include/private/svn_client_private.h libsvn_client/commit_util.c libsvn_client/copy.c libsvn_client/merge.c libsvn_client/mergeinfo.c libsvn_client/util.c

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 4 Apr 2012 09:34:38 -0400

On Apr 4, 2012 9:17 AM, "Julian Foad" <julianfoad_at_btopenworld.com> wrote:
>
> Greg Stein wrote:
> >> Convert svn_client__wc_node_get_origin() to use svn_client__pathrev_t
for
> >> its output.
> >>
> >> * subversion/include/private/svn_client_private.h,
> >> subversion/libsvn_client/util.c
> >> (svn_client__wc_node_get_origin): Use pathrev_t for the output.
>
> > This revision certainly shows how pathrev_t is a simplifying concept.
Very nice!
> > That said: I'd recommend being wary in your work about the struct being
an *input* param in public APIs. There are seriously heavy internal
constraints on the struct members. (eg. pass a struct with a NULL uuid, or
even a non-matching one)
> > I don't have a recommendation right now for what happens if the struct
is made public. I just wanted to raise a yellow flag. It seems best to keep
it very private because of the difficult constraints/preconditions in its
members.
>
>
> Right, good point. I'd really like to see this (or something similar)
become more widespread so I hope we can find a satisfactory solution.

It may be as simple as only returning const structs in the API. Or opaque.
But certainly warnings like, "seriously, don't mess around in here. tweak
at your own peril." :-)

Cheers,
-g
Received on 2012-04-04 15:35:12 CEST

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.