You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by br...@apache.org on 2015/03/17 14:08:24 UTC

svn commit: r1667295 - /subversion/branches/1.8.x/STATUS

Author: brane
Date: Tue Mar 17 13:08:24 2015
New Revision: 1667295

URL: http://svn.apache.org/r1667295
Log:
* branches/1.8.x/STATUS:
   - Vote for the r1660220 and r1619380 groups, and r1666690.
   - Approve r1660071, r1532287, r1660593, r1660646, r1663991 and r1664684.

Modified:
    subversion/branches/1.8.x/STATUS

Modified: subversion/branches/1.8.x/STATUS
URL: http://svn.apache.org/viewvc/subversion/branches/1.8.x/STATUS?rev=1667295&r1=1667294&r2=1667295&view=diff
==============================================================================
--- subversion/branches/1.8.x/STATUS (original)
+++ subversion/branches/1.8.x/STATUS Tue Mar 17 13:08:24 2015
@@ -47,14 +47,6 @@ Candidate changes:
      +0: danielsh (hard to review all potential causes of expanded_size==0 in
                    7*3*2 cases (1.1…1.8) × (file/dir/prop rep) × (plain/delta))
 
- * r1660071
-   When handling a pre-existing working copy as external, register it as such
-   Justification:
-     Without this the external is not properly handled as such when performing
-     operations like status.
-   Votes:
-     +1: rhuijben, stsp
-
  * r1660220, r1665874
    Don't leave conflict markers on files that are moved
    Branch:
@@ -63,9 +55,50 @@ Candidate changes:
      Without this patch property or text conflicted files that are moved
      leave dangling conflict markers in the old location. Easy fix.
    Votes:
-     +1: stsp
+     +1: stsp, brane
      +1: rhuijben (without r1665874)
 
+ * r1619380, r1619393, r1660186
+   Fix diff of a locally copied directory with props: it showed all props
+   as added instead of a diff against the copy-from props.
+   Justification:
+     Behaviour regression introduced in 1.8.0.
+   Notes:
+     r1619380 is the fix; r1619393 a test for it.
+     The test on trunk@1619393 is tweaked to account for a trunk bug in the
+     display of diff headers; the backport branch provides the correct
+     version for 1.8.x.
+   Branch:
+     ^/subversion/branches/1.8.x-r1619380
+   Votes:
+     +1: rhuijben, brane
+     +1: stefan2 (before r1660186 was added)
+     +0: julianfoad
+
+ * r1666690
+   Record skipped tree during merge on the skip root instead of leaves
+   Justification:
+     Resolves a user reported problem in merge handling. Avoids unnecessary
+     mergeinfo recording on multiple leaves when a single ancestor is shadowed.
+   Branch:
+     ^/subversion/branches/1.8.x-r1666690
+   Votes:
+     +1: rhuijben, brane
+
+Veto-blocked changes:
+=====================
+
+Approved changes:
+=================
+
+ * r1660071
+   When handling a pre-existing working copy as external, register it as such
+   Justification:
+     Without this the external is not properly handled as such when performing
+     operations like status.
+   Votes:
+     +1: rhuijben, stsp, brane
+
  * r1532287
    Simplify Windows resource compilation to avoid warnings
    Justification:
@@ -78,7 +111,7 @@ Candidate changes:
      multiple warnings for each .dll and .exe on the Windows buildbot,
      thereby hiding more important warnings)
    Votes:
-     +1: rhuijben, ivan
+     +1: rhuijben, ivan, brane
 
  * ^/subversion/branches/1.8.x-r1660593
    Fix recording last-* information on nodes copied from foreign repositories
@@ -91,14 +124,14 @@ Candidate changes:
    Branch:
      ^/subversion/branches/1.8.x-r1660593
    Votes:
-     +1: rhuijben, stsp
+     +1: rhuijben, stsp, brane
 
  * r1660646
    Fix calculating the repository path of replaced directories on entry upgrade
    Justification:
      Simple fix that avoids recording invalid data in WC-NG.
    Votes:
-     +1: rhuijben, stsp
+     +1: rhuijben, stsp, brane
 
  * r1663991
    Fix calculating the repository path after commits of nodes that are
@@ -107,7 +140,7 @@ Candidate changes:
      Allows introducing repository paths in the working copy, that don't
      reflect the repository state.
    Votes:
-     +1: rhuijben, stsp
+     +1: rhuijben, stsp, brane
 
  * r1664684
    svnrdump: don't provide HEAD+1 as base revision when loading deletes.
@@ -118,59 +151,4 @@ Candidate changes:
    Branch:
      ^/subversion/branches/1.8.x-r1664684
    Votes:
-     +1: rhuijben, stsp
-
- * r1619380, r1619393, r1660186
-   Fix diff of a locally copied directory with props: it showed all props
-   as added instead of a diff against the copy-from props.
-   Justification:
-     Behaviour regression introduced in 1.8.0.
-   Notes:
-     r1619380 is the fix; r1619393 a test for it.
-     The test on trunk@1619393 is tweaked to account for a trunk bug in the
-     display of diff headers; the backport branch provides the correct
-     version for 1.8.x.
-   Branch:
-     ^/subversion/branches/1.8.x-r1619380
-   Votes:
-     +1: rhuijben
-     +1: stefan2 (before r1660186 was added)
-     +0: julianfoad
-
- * r1666690
-   Record skipped tree during merge on the skip root instead of leaves
-   Justification:
-     Resolves a user reported problem in merge handling. Avoids unnecessary
-     mergeinfo recording on multiple leaves when a single ancestor is shadowed.
-   Branch:
-     ^/subversion/branches/1.8.x-r1666690
-   Votes:
-     +1: rhuijben
-
- * r1666965, r1667120
-   Reduce 'the lag' of the first svn log results over mod_dav.
-   Justification:
-     A slow svn log makes users call Subversion slow. This fixes the
-     perceived performance problem by no longer optimizing just for
-     obtaining all the results fast, but also for obtaining the first
-     result fast.
-     .
-     Just the perceived slowness of common svn log operations might
-     make users switch to a DVCS or implement a client side cache,
-     while this slowness is just a buffering to make the total set of
-     results come in faster. But I don't think there are that many users
-     that really wait for all results of
-     .
-     $ svn log -q ^/subversion/trunk
-     .
-     This currently takes > 10 seconds before the first result using
-     the EU mirror for me. With --limit 1 (best comparison with post-patch)
-     that would be 0.2 seconds.
-   Votes:
-     +1: rhuijben, philip (After it has been approved for 1.9)
-
-Veto-blocked changes:
-=====================
-
-Approved changes:
-=================
+     +1: rhuijben, stsp, brane



Re: svn commit: r1667295 - /subversion/branches/1.8.x/STATUS

Posted by Branko Čibej <br...@wandisco.com>.
On 17.03.2015 14:41, Ivan Zhakov wrote:
> On 17 March 2015 at 16:08,  <br...@apache.org> wrote:
>> Author: brane
>> Date: Tue Mar 17 13:08:24 2015
>> New Revision: 1667295
>>
>> URL: http://svn.apache.org/r1667295
>> Log:
>> * branches/1.8.x/STATUS:
>>    - Vote for the r1660220 and r1619380 groups, and r1666690.
>>    - Approve r1660071, r1532287, r1660593, r1660646, r1663991 and r1664684.
>>
> [....]
>
>> -
>> - * r1666965, r1667120
>> -   Reduce 'the lag' of the first svn log results over mod_dav.
>> -   Justification:
>> -     A slow svn log makes users call Subversion slow. This fixes the
>> -     perceived performance problem by no longer optimizing just for
>> -     obtaining all the results fast, but also for obtaining the first
>> -     result fast.
>> -     .
>> -     Just the perceived slowness of common svn log operations might
>> -     make users switch to a DVCS or implement a client side cache,
>> -     while this slowness is just a buffering to make the total set of
>> -     results come in faster. But I don't think there are that many users
>> -     that really wait for all results of
>> -     .
>> -     $ svn log -q ^/subversion/trunk
>> -     .
>> -     This currently takes > 10 seconds before the first result using
>> -     the EU mirror for me. With --limit 1 (best comparison with post-patch)
>> -     that would be 0.2 seconds.
>> -   Votes:
>> -     +1: rhuijben, philip (After it has been approved for 1.9)
> Hi Brane,
>
> It seems this nomination has been lost during this commit.
>
> On the nomination itself: I think this change should not be backported
> to 1.8.x: it's not security or bug fix. It the change itself a little
> bit controversial for me, so its better to release it as part of
> 1.9.x.

Meh, looks like I got my wires crossed, juggling too many changes in
STATUS at the same time. I'll put the nomination back; I didn't vote for
it. Thanks for noticing!

-- Brane

Re: svn commit: r1667295 - /subversion/branches/1.8.x/STATUS

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 17 March 2015 at 16:08,  <br...@apache.org> wrote:
> Author: brane
> Date: Tue Mar 17 13:08:24 2015
> New Revision: 1667295
>
> URL: http://svn.apache.org/r1667295
> Log:
> * branches/1.8.x/STATUS:
>    - Vote for the r1660220 and r1619380 groups, and r1666690.
>    - Approve r1660071, r1532287, r1660593, r1660646, r1663991 and r1664684.
>
[....]

> -
> - * r1666965, r1667120
> -   Reduce 'the lag' of the first svn log results over mod_dav.
> -   Justification:
> -     A slow svn log makes users call Subversion slow. This fixes the
> -     perceived performance problem by no longer optimizing just for
> -     obtaining all the results fast, but also for obtaining the first
> -     result fast.
> -     .
> -     Just the perceived slowness of common svn log operations might
> -     make users switch to a DVCS or implement a client side cache,
> -     while this slowness is just a buffering to make the total set of
> -     results come in faster. But I don't think there are that many users
> -     that really wait for all results of
> -     .
> -     $ svn log -q ^/subversion/trunk
> -     .
> -     This currently takes > 10 seconds before the first result using
> -     the EU mirror for me. With --limit 1 (best comparison with post-patch)
> -     that would be 0.2 seconds.
> -   Votes:
> -     +1: rhuijben, philip (After it has been approved for 1.9)
Hi Brane,

It seems this nomination has been lost during this commit.

On the nomination itself: I think this change should not be backported
to 1.8.x: it's not security or bug fix. It the change itself a little
bit controversial for me, so its better to release it as part of
1.9.x.

-- 
Ivan Zhakov