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

Re: Returning revprops through commit info

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 20 Aug 2010 16:46:51 -0400

Getting back to this...

On Thu, Aug 12, 2010 at 16:10, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Recently, we've updated the various client APIs which do commits to
> return commit info back through a callback[1], since they may be
> extended to perform multiple commits (see issue #1199 for instance).
> In doing so, I've had the opportunity to take a look at the
> svn_commit_info_t struct.  It's pretty simplistic, but includes fields
> for the author and date.
>
> In 1.6 (I believe) we changed the various log and commit APIs to use a
> hash of arbitrary revision properties, rather than a hard coded list.
> I wonder if it's worth it to do so in the commit_info struct.  We'd
> still keep the existing fields for compat, but we would also add a
> hash of revision properties, for consistency with the other APIs, and
> for greater future extensibility.
>
> Thoughts?

Sounds like something good for 1.8.

>
> -Hyrum
>
> [1] The callback was added as a member of the client context, instead
> of a per-API func/baton set.  This choice was somewhat arbitrary, and
> conversations with Mark regarding the same in the JavaHL wrappers have
> made me wonder if we should go with the explicit func/baton args,
> rather than using the client ctx.  Anybody have any strong feelings
> about this issue?

Adding more crap to the client ctx is bad. Yeah, I have strong
feelings about it :-P ... I'd very much request adding it as
parameters to *only* the functions which require it.

Once I get more Round Tuits, then I'd want to rev that context
structure to svn_client_ctx2 and strip it *way* down. Clean out
obsolete members, move some items into a private structure linked from
the publicly-visible context, and leave just a few that the client
should be able to set/get.

I have a similar problem with the merge_cmd_baton in client/merge.c.
It is a garbage can full of random things that people didn't want to
pass as arguments.

Cheers,
-g
Received on 2010-08-20 22:47:43 CEST

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