svn commit: r1158945 - /subversion/branches/1.7.x/STATUS

[st...@apache.org]

Author: stsp
Date: Wed Aug 17 22:24:46 2011
New Revision: 1158945

URL: http://svn.apache.org/viewvc?rev=1158945&view=rev
Log:
* STATUS: Nominate r1158617 and friends and family for backport.

Modified:
    subversion/branches/1.7.x/STATUS

Modified: subversion/branches/1.7.x/STATUS
URL: http://svn.apache.org/viewvc/subversion/branches/1.7.x/STATUS?rev=1158945&r1=1158944&r2=1158945&view=diff
==============================================================================
--- subversion/branches/1.7.x/STATUS (original)
+++ subversion/branches/1.7.x/STATUS Wed Aug 17 22:24:46 2011
@@ -141,6 +141,28 @@ Candidate changes:
    Votes:
      +1: rhuijben, hwright
 
+  * r1158617, r1158875, r1158886, r1158896, r1158919, r1158924
+    Make 'svn revert' remove unversioned files resulting from reverting a copy.
+    Fixes issue #3101.
+    Justification:
+      Bert suggested to backport this to 1.7.
+      I myself am not really sure if we should consider this a bug fix
+      or a behaviour change. I think we should merge this before 1.7.0
+      if we decide to merge it.
+      It does fix some fairly annoying usability issues.
+      For instance: If a merge adds files, the merge result is reverted, and
+      the merge is repeated, the second merge does not produce the same result
+      as the first merge. It will skip the, now unversioned, files added by
+      the first merge. There are various other cases where the unversioned
+      files get in the way.
+    Notes:
+      Instead of reviewing the individual commits I would suggest to run
+      the following merge and review the resulting diff:
+        svn merge -c1158617,1158875,1158886,1158896,1158919,1158924 \
+          ^/subversion/trunk
+    Votes:
+      +1: stsp (but only if this gets into 1.7.0)
+
 Veto-blocked changes:
 =====================