David James wrote:
> On Thu, Jul 17, 2008 at 12:49 PM, <hwright_at_tigris.org> wrote:
>> - self.client_ctx.log_msg_func2 = client.svn_swig_py_get_commit_log_func
>> - self.client_ctx.log_msg_baton2 = self.log_message_func
>> + self.assertEquals(self.client_ctx.log_msg_baton3, None)
>> + self.assertEquals(self.client_ctx.log_msg_func3, None)
>> + self.client_ctx.log_msg_func3 = client.svn_swig_py_get_commit_log_func
>> + self.client_ctx.log_msg_baton3 = self.log_message_func
> ...
>> - self.client_ctx.log_msg_func2(None, self.client_ctx.log_msg_baton2)
>> + self.client_ctx.log_msg_func3(None, self.client_ctx.log_msg_baton2)
>
> Shouldn't that be self.client_ctx.log_msg_baton3?
Yes, fixed in r32169.
> On Thu, Jul 17, 2008 at 1:34 PM, Blair Zajac <blair_at_orcaware.com> wrote:
>> So is the real problem is that somewhere either
>> client.svn_swig_py_get_commit_log_func or self.log_message_func changed what
>> its returning and we were putting this into the wrong client structure.
>> But the Python code using the callbacks hasn't changed, so isn't this a break
>> in our API? I mean, if I had this code in my own project using 1.4 and it now
>> core dumps in going to 1.5.1, isn't that an issue we should fix?
>
> You're right -- and yes, this is a problem.
> client.svn_swig_py_get_commit_log_func should be versioned, so that
> this kind of code can continue to work.
>
> As you pointed out, it probably makes more sense to update
> svn_swig_py_get_commit_log_func to be versioned properly rather than
> to work around the problems with it in the test suite.
David,
I agree that a more elegant solution would be preferable, and I'd like
to help, but this is out of my league (and I've got other fish to fry at
the moment). If it's something you think should be done in a soon-ish
release, could you take a look at versioning the commit log function?
Thanks,
-Hyrum
Received on 2008-07-18 06:24:56 CEST