[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Tue, 17 Aug 2010 11:56:16 -0500

On Mon, Aug 16, 2010 at 5:24 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> On Thu, 2010-08-12, Hyrum K. Wright 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?
> +1.

I'll go ahead and start working on this. It may entail extending the
various RA protocols, but I hope to be able to do this on trunk
instead of a branch. I know it isn't on the 1.7 blocking list, and
may seem like superflous code churn, but for completeness and
symmetry's sake, it just seems Right. (and helps placate my OCD....
:P )

>> [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?

Any thoughts on this issue?

Received on 2010-08-17 18:56:54 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.