Getting back to this... On Thu, Aug 12, 2010 at 16:10, Hyrum K. Wright <hyrum_wri...@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
