I used -0 to specifically say "I'm not in favor, but this is NOT a
veto." Just like any normal vote.
On Fri, Jun 5, 2009 at 13:38, Hyrum K.
> On Jun 5, 2009, at 12:48 PM, Bert Huijben wrote:
>>> -----Original Message-----
>>> From: Hyrum K. Wright [mailto:hyrum_at_hyrumwright.org]
>>> Sent: vrijdag 5 juni 2009 11:37
>>> To: svn_at_subversion.tigris.org
>>> Subject: svn commit: r37934 - in branches/1.6.x: .
>>> Author: hwright
>>> Date: Fri Jun 5 02:37:21 2009
>>> New Revision: 37934
>>> Merge r37890 from trunk:
>>> * r37890
>>> Fix issue #3347, "svn never times out when (public) IP changes"
>>> Simple fix. Helps automated svn client jobs using ra_svn in
>>> noticing various network-layer problems and giving up instead
>>> of just sitting there forever, waiting to be killed.
>>> +1: stsp, arfrever, rhuijben
>>> branches/1.6.x/ (props changed)
>>> branches/1.6.x/CHANGES (props changed)
>>> Modified: branches/1.6.x/STATUS
>>> --- branches/1.6.x/STATUS Fri Jun 5 01:19:29 2009 (r37933)
>>> +++ branches/1.6.x/STATUS Fri Jun 5 02:37:21 2009 (r37934)
>>> @@ -83,11 +83,3 @@ Approved changes:
>>> +1: pburba, rhuijben, arfrever
>>> -0: gstein (code bloat) (before r37618)
>> This leaves:
>> Approved changes:
>> * r37491, r37593, r37618
>> Another merge performance improvement: Reduce contacts with server when
>> a subtree with mergeinfo has non-inheritable mergeinfo and the subtree's
>> immediate children have no explicit mergeinfo.
>> If you hit this use case and the and the subtree in question has a
>> of immediate children without mergeinfo then this change will avoid
>> needless round trips for *each* of those children.
>> There is a call to svn_uri_basename() in
>> inherit_implicit_mereginfo_form_parent() that must be changed to
>> svn_path_basename() since the former is new for 1.7.
>> r37491 is the fix, r37593 is a typo fix, r37618 is some code
>> to address gstein's bloat concern.
>> +1: pburba, rhuijben, arfrever
>> -0: gstein (code bloat) (before r37618)
>> The code duplication gstein referenced in his mail was fixed in r37618 and
>> don't think his vote should be seen as a veto here?
> I don't think so either, especially since his concern has (hopefully) been
> addressed. I've been hoping Greg would surface sometime to address this,
> but it appears he's still busy with Real Life. Barring an explicit "-1",
> I'll go ahead and merge this group soon.
> PS - In looking in HACKING, I noticed we don't actually document -0
> anywhere. We've been using it for a while, perhaps we should update our
> guiding document to be more explicit about its nature?
Received on 2009-06-07 07:21:14 CEST