On Sun, Aug 22, 2010 at 1:02 PM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
> Hey Justin,
>
> On Sat, Aug 21, 2010 at 4:30 AM, <jerenkrantz_at_apache.org> wrote:
>> Author: jerenkrantz
>> Date: Sat Aug 21 02:30:31 2010
>> New Revision: 987689
>>
>> URL: http://svn.apache.org/viewvc?rev=987689&view=rev
>> Log:
>> Propose r879757 & r880320 for backport to 1.6.x.
>>
>> Modified:
>> subversion/branches/1.6.x/STATUS
>>
>> Modified: subversion/branches/1.6.x/STATUS
>> URL: http://svn.apache.org/viewvc/subversion/branches/1.6.x/STATUS?rev=987689&r1=987688&r2=987689&view=diff
>> ==============================================================================
>> --- subversion/branches/1.6.x/STATUS (original)
>> +++ subversion/branches/1.6.x/STATUS Sat Aug 21 02:30:31 2010
>> @@ -233,6 +233,17 @@ Candidate changes:
>> Votes:
>> +1: danielsh
>>
>> + * r879757, r880320
>> + Let ra_serf work with current serf releases.
>> + Justification:
>> + Having a dud client is bad. This seems to be the minimal required changes.
>> + Backport branch:
>> + ^/subversion/branches/1.6.x-r879757
>> + Notes:
>> + r879757 is the main fix. r880320 is a follow up fix.
>> + Votes:
>> + +1: jerenkrantz
>
> I didn't want to propose r879757 for backport because it changes the
> svn_ra_serf__conn_setup function declaration, which is used as a
> callback function for serf, in an incompatible way with serf 0.3. As
> long as one builds and runs svn with the same serf version there is no
> problem. The idea was to just raise the minimum serf version with svn
> 1.7 release, so this problem couldn't happen.
>
> Is this something we make promises about?
It has the ifdef so older serf's should work fine. Or, am I missing
something? Is the issue compiling against 0.4.x+ and running with
0.3.x+? If so, I'm not sure that's worth worrying about. (Serf
doesn't have a promise of binary API compatibility...)
The core issue that I'm trying to address in this backport is that we
don't have enough auto-fu checks currently in place to block
combinations of 1.6.x with current releases of serf. We have no
version checks at configure-time - only at compile-time; and the
compile-time checks in 1.6.x don't complain if it sees a serf version
it doesn't know about. So, right now, 1.6.x (without r879757) builds
"successfully", but due to the API mismatches, we get a dud client
with serf 0.4.0+ and 1.6.x. -- justin
Received on 2010-08-22 23:31:17 CEST