subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stef...@apache.org
Subject svn commit: r1451731 - /subversion/site/publish/docs/release-notes/1.8.html
Date Fri, 01 Mar 2013 22:06:39 GMT
Author: stefan2
Date: Fri Mar  1 22:06:38 2013
New Revision: 1451731

URL: http://svn.apache.org/r1451731
Log:
Update 1.8 release notes.

* publish/docs/release-notes/1.8.html
  (FSFS size and performance enhancements,
   Support for high-speed networks): tweak wording
  (In repository authz): typo
  (fsfs-stats): new section

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

Modified: subversion/site/publish/docs/release-notes/1.8.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.8.html?rev=1451731&r1=1451730&r2=1451731&view=diff
==============================================================================
--- subversion/site/publish/docs/release-notes/1.8.html (original)
+++ subversion/site/publish/docs/release-notes/1.8.html Fri Mar  1 22:06:38 2013
@@ -883,16 +883,16 @@ Some of these changes require a format b
 
 <p>The default repository format created by <tt>svnadmin create</tt> is
 now FSFS version 6 which is not be accessible to Subversion 1.7 or older.
+Older repository formats remain fully supported by Subversion 1.8 but
+will not support <a href="#revprop-packing">revprop packing</a>.
 To create FSFS repositories compatible with Subversion 1.6 and 1.7, use
-the <tt>--compatible-version 1.6</tt> parameter. Older repository formats
-remain fully supported by Subversion 1.8 but will not support 
-<a href="#revprop-packing">revprop packing</a>.</p>
+the <tt>--compatible-version 1.6</tt> parameter.</p>
 
 <p>You may use <tt>svnadmin upgrade</tt> to upgrade existing repositories.
 However, to fully benefit from the latest <a href="#fsfs-deltification">repository
size reductions</a>,
 it is recommended to create a new repository, adjust its settings and then
 <a href=http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate.svnadmin
->dump / load</a> or svnsync the content into it.
+>dump / load</a> or svnsync the contents into it.
 </p>
 
 </div>  <!-- fsfs-format-6 -->
@@ -905,22 +905,22 @@ it is recommended to create a new reposi
 
 <p><a href="#fsfs-format-6">Format 6 repositories</a> will not only
 pack the revision files but also the revision property files. Upgrading
-exisiting packed repositories will automatically pack the revision 
+exisiting packed repositories will automatically pack existing revision 
 properties. Using default settings, this will reduce the number of
 revprop files to less than 10 per 1000 revisions in typical usage
 scenarios.</p>
 
 <p>The <tt>db/fsfs.conf</tt> file allows you to fine-tune the
-revprop packing strategy (see the comments in that file for a
-detailed description of the available options). Please note that any
-change in this configuration file will not affect existing data.
+revprop packing strategy.  See the comments in that file for a
+detailed description of the available options.  Please note that no
+change in this configuration file will affect any existing data.
 Moreover, upgrading repositories will not extend the existing
 configuration file, i.e. the server will use the default settings
 unless the new options are added explicitly.</p>
 
-<p>It is recommended also to activate <a href="#revprop-caching"
+<p>It is recommended to also activate <a href="#revprop-caching"
 >revprop caching</a> when you use revprop packing. Otherwise, access
-to timestamps etc. will incur significant overhead.</p>
+to timestamps etc. will suffer significant processing overhead.</p>
 
 </div>  <!-- revprop-packing -->
 
@@ -931,8 +931,8 @@ to timestamps etc. will incur significan
 </h4>
 
 <p>Many operations will access revision properties to e.g. retrieve
-the commit time stamp. Therefore, thousands of revision property
-files may be read during a checkout. The UI to enable the revprop
+the commit time stamp. Therefore, thousands of revision property files
+may need to be read during a checkout. The UI to enable the revprop
 cache is similar to that for the other caches: <tt>svnserve</tt>
 now accepts the <tt>--cache-revprops yes</tt> parameter. For
 <tt>mod_dav_svn</tt>, the same looks like this in <tt>httpd.conf</tt>
@@ -945,8 +945,8 @@ now accepts the <tt>--cache-revprops yes
 
 <p>With <a href="#revprop-packing">revision property packing</a>
 enabled, revprop caching allows you to read hundreds of revprops
-at once from a single file. This can give e.g. <tt>svn log</tt>
-a significant performance boost.</p>
+at once from a single file. This can give a significant performance
+boost to e.g. <tt>svn log</tt> .</p>
 
 </div>  <!-- revprop-caching -->
 
@@ -956,7 +956,7 @@ a significant performance boost.</p>
     title="Link to this section">&para;</a>
 </h4>
 
-<p>For each changed node in an FSFS repository, new versions of 
+<p>For each changed node in a FSFS repository, new versions of 
 all parent directories will be created. Larger repositories tend
 to have relatively deep directory structures with at least one
 level (branches, modules or projects) having tens of entries.
@@ -976,20 +976,20 @@ individual options.
 </p>
 
 <p>Another optimization in 1.8 is that node properties with the
-same content will only be stored once and then referenced. This
-not only slightly reduces the size of the repository but greatly
-improves cache efficiency and can also significantly reduce I/O.
+same contents will only be stored once and then merely referenced.
+This not only slightly reduces the size of the repository but greatly
+improves cache effectiveness and may reduce I/O significantly.
 </p>
 
 <p><b>It's backward compatible!</b> Please note that the mechanism
-to read deltified data is the same for file content as for directories
+to read deltified data is the same for file contents as for directories
 and properties. Hence, Subversion 1.6 and 1.7 will be able to read
 them but will always write new revisions without that optimization.
 It is therefore perfectly legal to create a pre-1.8-compatible
 repository in 1.8, to enable various deltification options, to <a 
 href=http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate.svnadmin
 >dump / load</a> into that new repository using 1.8 tooling and to
-finally use it with a 1.6 or 1.7 server.
+finally use the repository with a 1.6 or 1.7 server.
 </p>
 
 </div>  <!-- fsfs-deltification -->
@@ -1000,11 +1000,11 @@ finally use it with a 1.6 or 1.7 server.
     title="Link to this section">&para;</a>
 </h4>
 
-<p>When representation sharing has been enabled, Subversion 1.8
-will now be able to detect identical files with content within
-the same revision and only store them once. This is a common situation
-when you for instance import a non-incremental dump file or when
-users apply the same change to multiple branches in a single commit.
+<p>When representation sharing has been enabled, Subversion 1.8 
+will now be able to detect files and properties with identical contents
+within the same revision and only store them once. This is a common
+situation when you for instance import a non-incremental dump file or
+when users apply the same change to multiple branches in a single commit.
 </p>
 
 </div>  <!-- fsfs-rep-sharing -->
@@ -1057,7 +1057,7 @@ relative path to a file outside a reposi
 
 <div class="notice"><span style="color: red"><b>WARNING:</b></span>Commiting
an
   authz file to a repository is no different than committing any other file.
-  The Subversion servers do not validate the authz file in anyway.  It may be
+  The Subversion servers do not validate the authz file in any way.  It may be
   desirable to setup a pre-commit hook script to validate the authz file is
   valid and/or has not removed all permissions to edit the file.  If
   permissions have been removed to edit it via the network server(s) you can
@@ -1078,7 +1078,7 @@ relative path to a file outside a reposi
 </h3>
 
 <div class="h4" id="benchmarking">
-<h4><tt>svn-bench</tt> Benchmarking client
+<h4><tt>svn-bench</tt> benchmarking client
   <a class="sectionlink" href="#benchmarking"
     title="Link to this section">&para;</a>
 </h4>
@@ -1114,6 +1114,57 @@ to what the client-side is seeing.</p>
 
 </div>  <!-- benchmarking -->
 
+<div class="h4" id="fsfs-stats">
+<h4><tt>fsfs-stats</tt> repository statistics
+  <a class="sectionlink" href="#fsfs-stats"
+    title="Link to this section">&para;</a>
+</h4>
+
+<p>This server-side tool will read a whole format 4 (Subversion 1.6)
+or newer repository and print out various statistics on the contents
+of the rev and pack files in it.  It starts of with very general 
+information and then breaks it down into various sub-demographics.
+The statistics include:
+
+<ul>
+  <li>Total repository size bytes</li>
+  <li>Number of revisions and changes</li>
+  <li>Sum of original and deltified file sizes</li>
+  <li>Sum of original and deltified directory sizes</li>
+  <li>Structural overhead due to node revisions, change lists etc.</li>
+  <li>Effectiveness of representation sharing</li>
+  <li>Paths and revisions of the 64 largest single changes</li>
+  <li>By file extension: Number of changes, total file size and total
+      internal representation size</li>
+  <li>Histograms on the above</li>
+</ul>
+</p>
+
+<p>Administrators may use this information to decide whether directory
+deltification should be enabled (ratio of directory representation
+vs. file representation sizes) or whether commit policies might to
+be revised (e.g. large .zip files accout for most of the repository).
+Some of the data, however, is useful for performance analysis by SVN
+developers only.</p>
+
+<pre>
+$ fsfs-stats /repositories/wesnoth_org 500 | gedit &
+</pre>
+
+<p><tt>fsfs-stats</tt> takes a local path to the repository root and
+an optional cache size parameter.  The latter is in MBytes and speeds
+up the analysis of large repositories.  Because the tool's output may
+be up to a 1000 lines of text, you may want to redirect it to some file
+or application.</p>
+
+<div class="notice">
+<p>Note that the 32 bit version of this tool may fail on repositories
+with millions of changes or with revision / pack files larger than 4 GB.
+Use a 64 bit executable instead for those repositories.</p>
+</div>
+
+</div>  <!-- fsfs-stats -->
+
 </div>  <!-- new-tools -->
 
 </div>  <!-- new-features -->
@@ -1376,22 +1427,22 @@ none, read-only, or read-write.</p>
 </h3>
 
 <p>If your server has a 10 Gbit/s or faster network connection, the
-multi-stage data copying from caches to the network stack plus frequent
-status checks become a bottleneck. Today, most clients won't be able
-to generate enough aggregated traffic to make this an issue and an 8-core
-server should be able to send about 40Gb/s at 100% CPU load. Future
-clients may be able, however, to process 1Gb or even 10Gb per second
-and to create significant server loads.
+multi-stage data copying from Subversion's caches to the network stack
+plus frequent status checks become a bottleneck. Today, most clients
+won't be able to generate enough aggregated traffic to make this an
+issue and an 8-core server should be able to send about 40Gb/s at 100%
+CPU load. Future clients may be able, however, to process 1Gb or even
+10Gb per second and to create significant server loads.
 </p>
 
 <p>When the server is given the <tt>--client-speed N</tt> parameter,
-it will assume that the clients are able to process data rates of 
-N Gbit/s; N being a non-negative integer. With N>0, the server will
-take various shortcuts to reduce the processing overhead. On the downside,
-it must employ strict time-outs to prevent clients from interfering
-each other: In any 1 second interval, a client must process incoming
-data at at least 2% of the specified speed or the operation may be
-aborted due to a timeout.
+it will assume that <tt>all</tt> clients are able to process data rates
+of N Gbit/s; N being a non-negative integer. With N>0, the server will
+take various shortcuts to reduce internal processing overhead. On the
+downside, it must employ strict time-outs to prevent clients from
+interfering each other: In any 1 second interval, a client must process
+incoming data with at least 2% of the specified speed - or the server
+may time out and abort the operation.
 </p>
 
 </div> <!-- svnserve -->



Mime
View raw message