subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From br...@apache.org
Subject svn commit: r1667295 - /subversion/branches/1.8.x/STATUS
Date Tue, 17 Mar 2015 13:08:24 GMT
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



Mime
View raw message