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