subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stef...@apache.org
Subject svn commit: r1694046 - /subversion/site/publish/docs/release-notes/1.9.html
Date Tue, 04 Aug 2015 12:21:40 GMT
Author: stefan2
Date: Tue Aug  4 12:21:39 2015
New Revision: 1694046

URL: http://svn.apache.org/r1694046
Log:
* publish/docs/release-notes/1.9.html
  (#svnadmin-verify): Polish, removing a redundant FSFSv7 part.

Modified:
    subversion/site/publish/docs/release-notes/1.9.html

Modified: subversion/site/publish/docs/release-notes/1.9.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.9.html?rev=1694046&r1=1694045&r2=1694046&view=diff
==============================================================================
--- subversion/site/publish/docs/release-notes/1.9.html (original)
+++ subversion/site/publish/docs/release-notes/1.9.html Tue Aug  4 12:21:39 2015
@@ -966,19 +966,17 @@ revision such that multiple issues may b
 has multiple issues and depending on the verification logic, still only the
 first problem may be reported.</p>
 
-<p>Thorough verification is expensive and will gets slower as the repository
-history grows.  FSFS format 7 repositories not only protect the reconstructed
-user data with checksums but also the deltified on-disk representation.  The
-new <tt>--metadata-only</tt> flag will skip the expensive internal consistency
-checks and reconstruction of all user data.</p>
+<p>Thorough verification is expensive and becomes slower as the repository
+history grows.  The new <tt>--metadata-only</tt> flag will skip the expensive
+internal consistency checks and reconstruction of all user data.</p>
 
 <p>In format 7 repositories, this will still perform a quick on-disk checksum
-test of everything data in rev / pack files but will only detect cases where
+test of all data in rev / pack files but will only detect cases where
 external forces (storage crash, rogue scripts etc.) modified committed data.
 Also, the checksums are weaker (about a 1 in a billion chance that a random
 change remains undetected) than the ones used to protect the user data.  If
-you suspect internal repository corruption such as caused by a bug within SVN
-itself, you still need to run a full verification.</p>
+you suspect internal repository corruption caused by a bug within SVN itself,
+you still need to run a full verification.</p>
 
 </div>  <!-- svnadmin-verify -->
 



Mime
View raw message