On Mon, Aug 16, 2010 at 5:24 AM, Julian Foad <julian.f...@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
