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
> a subtree with mergeinfo has non-inheritable mergeinfo and the
> 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
> 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 I
> 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-05 13:39:01 CEST