[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r987689 - /subversion/branches/1.6.x/STATUS

From: Greg Stein <gstein_at_gmail.com>
Date: Sun, 22 Aug 2010 22:25:33 -0400

On Sun, Aug 22, 2010 at 17:30, Justin Erenkrantz <justin_at_erenkrantz.com> wrote:
> 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

I also added an API to serf to facilitate runtime version checks (ie.
hopefully before a call to a bogus signature is performed). But that
call is only in later versions :-P

Cheers,
-g
Received on 2010-08-23 04:26:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.