subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1159539 - /subversion/site/publish/docs/release-notes/1.8.html
Date Fri, 19 Aug 2011 08:27:25 GMT
Author: danielsh
Date: Fri Aug 19 08:27:24 2011
New Revision: 1159539

Add a 1.8 release notes skeleton, based on the 1.7 release notes.

* /site/publish/docs/release-notes/1.8.html

      - copied, changed from r1159533, subversion/site/publish/docs/release-notes/1.7.html

Copied: subversion/site/publish/docs/release-notes/1.8.html (from r1159533, subversion/site/publish/docs/release-notes/1.7.html)
--- subversion/site/publish/docs/release-notes/1.7.html (original)
+++ subversion/site/publish/docs/release-notes/1.8.html Fri Aug 19 08:27:24 2011
@@ -2,7 +2,7 @@
 <html xmlns="">
-<title>Apache Subversion 1.7 Release Notes</title>
+<title>Apache Subversion 1.8 Release Notes</title>
 <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
 <style type="text/css">
   @import url("/style/site.css");
@@ -17,45 +17,44 @@
 <!-- **************** BEGIN CONTENT ***************** -->
 <div class="notice">
-<p><strong>Note:</strong> Subversion 1.7 is <em>not released yet</em>.
+<p><strong>Note:</strong> Subversion 1.8 is <em>not released yet</em>.
 When it is released, this warning message will disappear, and the rest
 of this page will become the release notes.  Until then, this page
 describes what is planned for the release.</p>
-<h1 style="text-align: center">Apache Subversion 1.7 Release Notes</h1>
+<div class="notice">
+<p><strong>Note to editors:</strong> "XXX(1.7)" sections are placeholders
+  and should be removed once parallel 1.8 content is added.</p>
+<h1 style="text-align: center">Apache Subversion 1.8 Release Notes</h1>
 <div class="h2" id="news">
-<h2>What's New in Apache Subversion 1.7
+<h2>What's New in Apache Subversion 1.8
   <a class="sectionlink" href="#news"
     title="Link to this section">&para;</a>
-  <li><a href="#wc-ng"
-      >Working Copy Metadata Storage Improvements</a></li>
-  <li><a href="#svnrdump"
-      >New remote dumpfile tool: <tt>svnrdump</tt></a></li>
-  <li><a href="#httpv2"
-      >Improved HTTP protocol usage</a></li>
   <li><a href="#patch"
-      >New feature: svn patch</a></li>
+      >XXX(1.7) New feature: svn patch</a></li>
   <li><a href="#enhancements"
       >Many enhancements and bug fixes</a></li>
   <li><a href="#distribution-changes"
       >Dependency, license and distribution changes</a></li>
-<p>Apache Subversion 1.7 is a superset of all previous Subversion
+<p>Apache Subversion 1.8 is a superset of all previous Subversion
 releases, and is as of the time of its release considered the current
 "best" release.  Any feature or bugfix in 1.0.x through 1.6.x is also
-in 1.7, but 1.7 contains features and bugfixes not present in any
+in 1.8, but 1.8 contains features and bugfixes not present in any
 earlier release.  The new features will eventually be documented in a
-1.7 version of the free Subversion book
+1.8 version of the free Subversion book
 (<a href="" ></a>).</p>
 <p>This page describes only major changes.  For a complete list of
-changes, see the 1.7 section of the <a
+changes, see the 1.8 section of the <a
 href="" >CHANGES</a>
@@ -67,34 +66,30 @@ file.</p>
     title="Link to this section">&para;</a>
-<p>Older clients and servers interoperate transparently with 1.7
-servers and clients.  However, some of the new 1.7 features may not be
+<p>Older clients and servers interoperate transparently with 1.8
+servers and clients.  However, some of the new 1.8 features may not be
 available unless both client and server are the latest version.  There are
 also cases where a new feature will work but will run less efficiently if
 the client is new and the server old.</p>
 <p>There is <strong>no need</strong> to dump and reload your
-repositories.  Subversion 1.7 can read repositories created by earlier
+repositories.  Subversion 1.8 can read repositories created by earlier
 versions.  To upgrade an existing installation, just install the
 newest libraries and binaries on top of the older ones.</p>
-<p>Subversion 1.7 maintains API/ABI compatibility with earlier
+<p>Subversion 1.8 maintains API/ABI compatibility with earlier
 releases, by only adding new functions, never removing old ones.  A
 program written to any previous 1.x API can both compile
-and run using 1.7 libraries.  However, a program written for 1.7
+and run using 1.8 libraries.  However, a program written for 1.8
 cannot necessarily compile or run against older libraries.</p>
 <p>There may be limited cases where the behavior of old APIs has been
 slightly modified from previous releases.  These are cases where edge cases
 of the functionality has been deemed buggy, and therefore improved or removed.
 Please consult the
-<a href=""
+<a href=""
 >API errata</a> for more detailed information on what these APIs are
-and what impact these changes may have.  For Subversion 1.7, these
-errata are mostly limited to <code>libsvn_wc</code>, with one notable
-exception: <code>libsvn_ra_serf</code>'s approach to driving
-the <code>svn_delta_editor_t</code> interfaces (provided to it indirectly
-via calls to the <code>svn_ra.h</code> interfaces).</p>
+and what impact these changes may have.</p>
 <div class="h3" id="new-feature-compatibility-table">
 <h3>New Feature Compatibility Table
@@ -109,7 +104,7 @@ via calls to the <code>svn_ra.h</code> i
     <th>Minimum Repository</th>
-    <td><a href="#httpv2">HTTPv2</a></td>
+    <td><a href="#httpv2">XXX(1.7) HTTPv2</a></td>
@@ -117,51 +112,6 @@ via calls to the <code>svn_ra.h</code> i
       function at the pre-1.7 feature level. Server-side configuration
       changes might be required for optimal performance with clients that
       use <a href="#serf">serf</a>.</td></tr>
-  <tr>
-    <td><a href="#wc-ng">WC-NG</a></td>
-    <td>1.7</td>
-    <td>any</td>
-    <td>any</td>
-    <td>1.6 working copies cannot be used with 1.7 and will
-        <strong>not</strong> be upgraded to the new 1.7 format
-        automatically.</td></tr>
-  <tr>
-    <td><a href="#svnrdump">svnrdump</a></td>
-    <td>1.7</td>
-    <td>any&nbsp;(dump)<br>1.7&nbsp;(load)</td>
-    <td>any</td>
-    <td><tt>svnrdump load</tt> should only be used with 1.7 servers
-        to avoid a race condition (see <a href="#svnrdump">below</a>).</td></tr>
-  <tr>
-    <td><a href="#patch">svn patch</a></td>
-    <td>1.7</td>
-    <td>any</td>
-    <td>any</td>
-    <td></td></tr>
-  <tr>
-    <td><a href="#atomic-revprops">atomic revprop changes</a></td>
-    <td>1.7</td>
-    <td>1.7</td>
-    <td>any</td>
-    <td>Fixes a race condition in <tt>svnsync</tt> (<a
-        href=""
-        >issue #3546</a>).</td></tr>
-  <tr>
-    <td><a href="#subtree-mergeinfo-recording">reduced subtree mergeinfo 
-      recording</a></td>
-    <td>1.7</td>
-    <td>any</td>
-    <td>any</td>
-    <td>If both pre-1.7 clients and 1.7 clients are used to perform merges 
-      to the same branch, the pre-1.7 clients may experience slower merge 
-      performance.</td></tr>
-  <tr>
-    <td><a href="#server-performance-tuning">server performance tuning</a></td>
-    <td>any</td>
-    <td>1.7</td>
-    <td>any</td>
-    <td>Purely server-side configuration. file:// access in 1.7 clients will
-      use the default settings.</td></tr>
      <td colspan="5"><sup>1</sup>Reminder: when using the <tt>file://</tt>
        repository access method, the Subversion program is both the client
@@ -206,7 +156,7 @@ example illustrates these changes.</p>
 <div class="h4" id="multi-update">
-<h4>Improved output of <tt>svn update</tt> for multiple working copies
+<h4>XXX(1.7) Improved output of <tt>svn update</tt> for multiple working
   <a class="sectionlink" href="#multi-update"
     title="Link to this section">&para;</a>
@@ -232,72 +182,6 @@ when updating multiple working copies at
 </div> <!-- multi-update -->
-<div class="h4" id="diff-properties">
-<h4><tt>svn diff</tt> now shows property changes as unidiff
-  <a class="sectionlink" href="#diff-properties"
-    title="Link to this section">&para;</a>
-<p><tt>svn diff</tt> now shows textual property changes in unidiff format,
-except for <tt>svn:mergeinfo</tt> properties.
-Below is an example of the new output:</p>
-  $ svn diff
-  Index: gamma
-  ===================================================================
-  --- gamma       (revision 23)
-  +++ gamma       (working copy)
-  Property changes on: gamma
-  ___________________________________________________________________
-  Modified: svn:externals
-  ## -1,3 +1,3 ##
-   ^/branches/gamma gamma-external
-  -^/trunk/alpha alpha-external
-  +^/trunk/beta beta-external
-   ^/trunk/epsilon epsilon-external
-  Index: beta
-  ===================================================================
-  --- beta        (revision 23)
-  +++ beta        (working copy)
-  Property changes on: beta
-  ___________________________________________________________________
-  Added: svn:eol-style
-  ## -0,0 +1 ##
-  +native
-</div> <!-- diff-properties -->
-<div class="h4" id="error-numbers">
-<h4>Error and warning numbers now reported
-  <a class="sectionlink" href="#error-numbers"
-    title="Link to this section">&para;</a>
-<p>The output of <tt>svn</tt> now contains an error number or warning
-number with every error.  The following example illustrates these changes.</p>
-   % svn info
-   svn: E155007: '/home/CIA-91' is not a working copy
-<p>These error values are useful as search keywords.  Under the hood, these error
-codes correspond to the <a href="/docs/api/latest/svn__error__codes_8h_source.html"
->API error codes</a> used by Subversion and APR.  For programming to our API's,
-it's possible to convert a numeric error code to a symbolic one via the <a
-></a> script (first included in Subversion 1.3.0):</p>
-   % ./tools/dev/ 155007
 </div>  <!-- output-changes -->
 <div class="h3" id="compat-misc">
@@ -311,7 +195,7 @@ release might necessitate further adjust
 users.  We'll cover those in this section.</p>
 <div class="h4" id="case-sensitive-authz">
-<h4>Case sensitivity of authz access rules
+<h4>XXX(1.7) Case sensitivity of authz access rules
   <a class="sectionlink" href="#case-sensitive-authz"
     title="Link to this section">&para;</a>
@@ -331,46 +215,6 @@ see <a href="http://subversion.tigris.or
 </div>  <!-- case-sensitive-authz -->
-<div class="h4" id="revprop-packing">
-<h4>Incompatible FSFS changes since 1.7.0-alpha3 for packed repositories
-  <a class="sectionlink" href="#revprop-packing"
-    title="Link to this section">&para;</a>
-<p>Subversion 1.6 introduced support for <a href="1.6.html#fsfs-packing">packing
-  FSFS revision files</a>, and Subversion 1.7.x alpha releases (up to
-1.7.0-alpha3) supported packing of revprops into an SQLite database.  This
-support is not present in the final release (see <a
->issue #3952</a> for the reason).  Any
-FSFS-backed repositories that were <tt>svnadmin create</tt>d or
-<tt>svnadmin upgrade</tt>d by <tt>svnadmin</tt> from a nightly build
-from an alpha release of the 1.7.x line are <strong>not</strong> supported by
-the final 1.7.0 release.  It is required to <tt>dump</tt> these repositories
-using an <tt>svnadmin</tt> built from the 1.7.0-alpha3 release in order to
-upgrade them for the 1.7.0 release.</p>
-<p>Subversion 1.7 will complain when it encounters such repositories, with
-the following error:</p>
-subversion/libsvn_fs_fs/fs_fs.c:1083: (apr_err=160043)
-svnadmin: E160043: Found format '5', only created by unreleased dev builds;
-   see <a href=""></a>
-<p>We reiterate that this lack of upgrade path is within the latitude of
-our <a href="/prerelease-caveats">policy for pre-releases</a>.  We may
-provide in the future a script to downgrade a repository in-place to the
-format supported by both 1.6 and 1.7.  (We will welcome <a href="/contributing"
->contributions</a> of such a script.)</p>
-<p>We plan to reintroduce revprop packing in a future release; see <a
->issue #3944</a> for details.</p>
-</div>  <!-- revprop-packing -->
 </div>  <!-- compat-misc -->
 </div>  <!-- compatibility -->
@@ -382,7 +226,7 @@ href="
 <div class="h3" id="wc-ng">
-<h3>Working Copy Metadata Storage Improvements (<em>client</em>)
+<h3>XXX(1.7) Working Copy Metadata Storage Improvements (<em>client</em>)
   <a class="sectionlink" href="#wc-ng"
     title="Link to this section">&para;</a>
@@ -484,115 +328,27 @@ practical to simply checkout a new worki
 </div>  <!-- wc-ng -->
 <div class="h3" id="httpv2">
-<h3>Improved HTTP protocol usage (<em>client</em> and <em>server</em>)
+<h3>XXX(1.7) Improved HTTP protocol usage (<em>client</em> and <em>server</em>)
   <a class="sectionlink" href="#httpv2"
     title="Link to this section">&para;</a>
-<p>Over the years, many people have complained about the performance issues
-with Subversion's use of HTTP as a repository access mechanism.  This largely
-stems from the developers' original intent to implement as much of the WebDAV
-<a href="">DeltaV</a> specification as
-possible.  Alas, this specification was not widely implemented, so
-none of the supposed benefits of the DeltaV overhead ever
-<p>Subversion 1.7 offers a simpler HTTP protocol variant that can be used when
-connecting to supported servers.  This simpler protocol (sometimes referred to
-as <em>HTTPv2</em>) requires fewer client-server round trips to establish a
-connection, making Subversion much more performant on high-latency network
-connections.  Subversion's Serf-based repository access library (which will
-<a href="#serf">become the default</a> library for HTTP in Subversion 1.8) has
-all of the protocol changes scheduled for 1.7, affecting both commit and read
-operations; the older Neon-based library has received the most important and
-high-impact of these changes, too.</p>
-<p>As mentioned in the <a href="#new-feature-compatibility-table">compatibility
-table</a>, Subversion 1.7 will only use HTTPv2 when connecting with a 1.7 (or
-greater) server, but will continue to use existing protocols when communicating
-with earlier versions of Subversion.  Likewise, older clients will only use the
-old protocol when connecting to a Subversion server, regardless of version.</p>
 </div>  <!-- httpv2 -->
 <div class="h3" id="svnrdump">
-<h3>New remote dumpfile tool: <tt>svnrdump</tt> (<em>client</em>)
+<h3>XXX(1.7) New remote dumpfile tool: <tt>svnrdump</tt> (<em>client</em>)
   <a class="sectionlink" href="#svnrdump"
     title="Link to this section">&para;</a>
-<p>Subversion 1.7 adds a new tool to the client's toolbox:
-<tt>svnrdump</tt>.  <tt>svnrdump</tt> replicates the functionality
-<tt>svnadmin dump</tt> and <tt>svnadmin load</tt>, but works on
-remote repositories, instead of needing administrator (local filesystem) access
-to the source or target repository.</p>
-<p>Note that <tt>svnrdump load</tt> can suffer from a race condition
-in its locking algorithm when run against a 1.6 or earlier server.
-This is the same problem that the new <a href="#atomic-revprops"
->atomic revprop changes feature</a> fixes for
-<tt>svnsync</tt> (see <a
- >issue #3546</a>), and the same <a href="#atomic-revprops">server-side
-workaround</a> is available.</p>
-<p>Server administrators who would like to block their users
-from committing via <tt>svnrdump load</tt> may do so by installing the
-following <tt>pre-revprop-change</tt> script:</p>
-if [ "$PROPNAME" = "svn:rdump-lock" ]; then
-  echo "'svnrdump load' disabled by the server administrator" &gt;&amp;2
-  exit 1
-exit 0
-<p>This hook script suffices to protect repositories from <em>accidental</em>
-of <tt>svnrdump load</tt>.  It does not (and cannot) protect the server from

-users who intentionally recompile <tt>svnrdump</tt> in order to bypass this
 </div>  <!-- svnrdump -->
 <div class="h3" id="patch">
-<h3>New feature: <tt>svn patch</tt> (<em>client</em>)
+<h3>XXX(1.7) New feature: <tt>svn patch</tt> (<em>client</em>)
   <a class="sectionlink" href="#patch"
     title="Link to this section">&para;</a>
-<p>Subversion 1.7 features a new subcommand called <tt>svn patch</tt>
-which can apply patch files in unidiff format (as produced by
-<tt>svn diff</tt> and other diff tools) to a working copy.</p>
-<p><tt>svn patch</tt> will apply unidiff changes to existing files just
-like third party patch tools.
-It will also add newly created files to version control, and delete files
-and directories which are left empty after patching.
-Keywords and newlines are also handled automatically if the
-<tt>svn:keywords</tt> and <tt>svn:eol-style</tt> properties are
-set on patched files.</p>
-<p><tt>svn diff</tt> will now produce unidiff output for Subversion
-property changes, and <tt>svn patch</tt> is able to apply these changes
-to properties (except for <tt>svn:mergeinfo</tt>, see
-<a href=""
-  >issue #3747</a>).</p>
-<p>When a patch does not apply cleanly some or all changes listed in the
-patch might be rejected. But <tt>svn patch</tt> currently does not
-mark files with rejected changes as conflicted (see
-<a href=""
-  >issue #3565</a>). Files which weren't patched successfully can be
-committed without being touched by <tt>svn resolve</tt> first.
-This problem will be addressed in a future release of Subversion.</p>
-<p>A new API for parsing unidiff patch files has been added to
-<code>libsvn_diff</code>. A new API for applying unidiff patches to a
-working copy has been added to <code>libsvn_client</code>.</p>
 </div>  <!-- patch -->
@@ -616,14 +372,14 @@ working copy has been added to <code>lib
 <p>There are far too many enhancements and new options to the
 command-line client to list them all here.  Aside from all the ones
 mentioned already in these release notes, below are a few more that we
-consider important, but please see the 1.7.0 section in the <a
+consider important, but please see the 1.8.0 section in the <a
 href="">CHANGES</a> file
 for a complete list.</p>
 <!-- Insert selected items here -->
 <div class="h4" id="log-diff">
-<h4>svn log can now print diffs
+<h4>XXX(1.7) svn log can now print diffs
   <a class="sectionlink" href="#log-diff"
     title="Link to this section">&para;</a>
@@ -658,148 +414,6 @@ a unified diff. Below is example output:
 </div>  <!-- log-diff -->
-<div class="h4" id="update-parents">
-<h4>svn update now accepts the --parents option
-  <a class="sectionlink" href="#update-parents"
-    title="Link to this section">&para;</a>
-<p><tt>svn update</tt> now accepts the <strong><tt>--parents</tt></strong>
-option. This option removes the need to manually create missing parent
-directories when adding additional items to a sparse working copy.</p>
-<p>For example, adding 3 files from different directories to a sparse
-working copy required creating each file's parent directories first:</p>
-   $ svn co --depth=empty ${PROJECT_ROOT_URL} wc
-   $ svn up --depth=empty wc/A wc/A/D wc/A/D/G wc/A/D/H wc/A/B wc/A/B/E
-   $ svn up wc/A/D/G/pi wc/A/D/H/omega wc/A/B/E/alpha
-<p>This becomes much easier with the new --parents option:</p>
-   $ svn co --depth=empty ${PROJECT_ROOT_URL} wc
-   $ svn up --parents wc/A/D/G/pi wc/A/D/H/omega wc/A/B/E/alpha
-</div>  <!-- update-parents -->
-<div class="h4" id="svn-relocate">
-<h4>New subcommand: svn relocate
-  <a class="sectionlink" href="#svn-relocate"
-    title="Link to this section">&para;</a>
-<p>A new <tt>svn relocate</tt> subcommand has been added.
-It points a working copy to a different repository root URL, serving
-the same purpose as the old <tt>svn switch --relocate</tt> syntax
-which has now been deprecated.
-</div>  <!-- svn-relocate -->
-<div class="h4" id="switch-ancestry-check">
-<h4>svn switch now checks ancestry
-  <a class="sectionlink" href="#switch-ancestry-check"
-    title="Link to this section">&para;</a>
-<p><tt>svn switch</tt> now checks that the working copy item being
-switched shares common version control history with the URL to which
-it is being switched.</p>
-<p>This change was made to protect users from the unpleasant side
-effects of oft-mistyped switch commands, such as accidentally
-running <tt>svn switch ^/branches</tt> when you instead meant to
-run <tt>svn switch ^/branches/<em>SOME-BRANCH</em></tt>.  As of
-version 1.7, Subversion will check to see if the source URL and the
-target working copy item are ancestrally related and, if they do not,
-the switch operation will fail with an error.</p>
-   $ svn switch ^/branches
-   svn: E195012: Path '.' does not share common version control ancestry
-   with the requested switch location.  Use --ignore-ancestry to disable
-   this check.
-   $
-<p>What is meant by "ancestrally related"?  In short, it means that if
-you were to compare all the paths and revisions that each of these two
-version controlled items has occupied over time &mdash; its current
-repository location plus all previous ones, back through all the
-copies and moves in its history &mdash; those two sets would
-<p>As noted in the previous example's error message, this ancestry
-check &mdash; which does come at some performance cost &mdash; may be
-disabled by passing the <strong><tt>--ignore-ancestry</tt></strong>
-option to the <tt>svn switch</tt> command.</p>
-</div>  <!-- switch-ancestry-check -->
-<div class="h4" id="diff-show-copies-as-adds">
-<h4>svn diff can show copied files as if they were newly added
-  <a class="sectionlink" href="#diff-show-copies-as-adds"
-    title="Link to this section">&para;</a>
-<p>When <tt>svn diff</tt> shows a copied file, it usually shows how the
-copied file differs from the file it was copied from.
-Sometimes this isn't the desired form of output. There are situations where
-a copied file needs to appear in its entirety, for instance when producing
-a patch file to be applied elsewhere with a patch tool (such as
-<a href="#patch"><tt>svn patch</tt></a>).</p>
-<p>In Subversion 1.7, <tt>svn diff</tt> takes a new
-<strong><tt>--show-copies-as-adds</tt></strong> option which causes
-files to be shown in their entirety, just like newly added files are shown.</p>
-</div>  <!-- diff-show-copies-as-adds -->
-<div class="h4" id="diff-git">
-<h4>svn diff can show git-style diff annotations
-  <a class="sectionlink" href="#diff-git"
-    title="Link to this section">&para;</a>
-<p><tt>svn diff</tt> takes a new
-<strong><tt>--git</tt></strong> option which causes it to produce
-annotations denoting added, deleted, and copied files.
-This extended diff format was inspired by
-<a href=""
-<p><tt>svn diff --git</tt> is intended to produce patches which are
-compatible to
-<a href=""
->git-apply</a>, but there are limitations due to differences between
-Subversion and git:
-  <li><tt>svn diff</tt> currently cannot display rename information.
-      Renames are always shown as a copy and a delete.</li>
-  <li>All paths in patches are shown relative to the repository root to
-      avoid ambiguity. It is possible that the numbers of leading path
-      components on the left and right side of the patch differ,
-      for instance if a diff between <tt>/trunk</tt> and
-      <tt>/branches/mybranch</tt> is shown.
-      This may prevent git-apply from applying such patches without
-      modification.</li>
-<p>In a future release of Subversion,
-<a href="#patch"><tt>svn patch</tt></a> will receive support for
-extra annotations produced by <tt>svn diff --git</tt>, so that additions,
-copies, renames, and deletions can be handled explicitly rather than
-<p>The same diff format extensions are also supported by
-<a href="">Mercurial</a>.</p>
-</div>  <!-- diff-git -->
-<div class="h4" id="svn-help-merge">
-<h4>svn merge help text has been enhanced
-  <a class="sectionlink" href="#svn-help-merge"
-    title="Link to this section">&para;</a>
-<p>The help text for the <tt>svn merge</tt> command has been enhanced.
-It now explains common use cases and includes small examples, making it
-more useful for quick reference.
-</div>  <!-- svn-help-merge -->
 </div>  <!-- cmdline -->
 <div class="h3" id="apis">
@@ -809,9 +423,9 @@ more useful for quick reference.
     title="Link to this section">&para;</a>
-<p>There are too many new and revised APIs in Subversion 1.7.0 to list
+<p>There are too many new and revised APIs in Subversion 1.8.0 to list
 them all here.  See the <a
-href="" >Subversion API
+href="" >Subversion API
 Documentation</a> page for general API information.  If you develop a
 3rd-party client application that uses Subversion APIs, you should
 probably look at the header files for the interfaces you use and see
@@ -820,7 +434,7 @@ what's changed.</p>
 <p>As noted <a href="#compatibility">above</a>, a small number of APIs
 <code>libsvn_wc</code> have slightly changed functionality from their
 historical roots.  Each of these cases has been documented as an
-<a href="">errata</a>,
+<a href="">errata</a>,
 detailing the impact of these changes.  All of the errata were the result of
 behavior which was deemed buggy, and the API changes are an attempt to fix
 these bugs.  The circumstances under which each is triggered are relatively
@@ -829,24 +443,6 @@ rare, and we anticipate the actual impac
 <p>Language bindings have mostly been updated for the new APIs, though
 some may lag more than others.</p>
-<div class="h4" id="javahl">
-<h4>JavaHL Updates
-  <a class="sectionlink" href="#javahl"
-    title="Link to this section">&para;</a>
-<p>Due to the move to the Apache Software Foundation, the JavaHL bindings
-have been similarly moved to a new package: <code>org.apache.subversion</code>.
-The old package still exists, and will continue to ship for backward
-compatibility reasons, but we recommend comsumers switch to the new package,
-as only it will continue to be updated.</p>
-<p>Also, JavaHL now requires Java 1.5 to compile.  In addition, many of the APIs
-in the new package have been switch to use generics, and other Java 1.5
-language features.</p>
-</div>  <!-- javahl -->
 </div>  <!-- apis -->
 <div class="h3" id="bug-fixes">
@@ -855,14 +451,14 @@ language features.</p>
     title="Link to this section">&para;</a>
-<p>A great many bugs have been fixed.  See the 1.7.0 section in the <a
+<p>A great many bugs have been fixed.  See the 1.8.0 section in the <a
 href="">CHANGES</a> file
 for details.</p>
 </div>  <!-- bug-fixes -->
 <div class="h3" id="serf">
-<h3>Serf HTTP library improved and stabilized (<em>client</em>)
+<h3>XXX(1.7) Serf HTTP library improved and stabilized (<em>client</em>)
   <a class="sectionlink" href="#serf"
     title="Link to this section">&para;</a>
@@ -917,7 +513,7 @@ growth of httpd server logs than neon cl
 </div>  <!-- serf -->
 <div class="h3" id="http-redirects">
-<h3>Improved handling of HTTP redirects (<em>client</em>)
+<h3>XXX(1.7) Improved handling of HTTP redirects (<em>client</em>)
   <a class="sectionlink" href="#http-redirects"
     title="Link to this section">&para;</a>
@@ -931,25 +527,6 @@ redirects (<tt>302 Found</tt> and <tt>30
 </div>  <!-- http-redirects -->
-<div class="h3" id="atomic-revprops">
-<h3>Atomic revprop changes (<em>client</em> and <em>server</em>)
-  <a class="sectionlink" href="#atomic-revprops"
-    title="Link to this section">&para;</a>
-<p>Revprop changes are now handled atomically.
-This fixes a known race condition in the locking algorithm used by
-<tt>svnsync</tt> (see <a
- >issue #3546</a>).  It is possible to fix the svnsync race condition
-even for pre-1.7 svnsync clients by installing the pre-revprop-change hook
-script given in
-<a href=""
- >comment 12 of issue #3546</a>.  (The hook script requires a 1.7 or newer
-<em>server</em> for correctness.)</p>
-</div>  <!-- atomic-revprops -->
 <div class="h3" id="merge-tracking-enhancements">
 <h3>Merge-Tracking Enhancements
   <a class="sectionlink" href="#merge-tracking-enhancements"
@@ -958,12 +535,12 @@ script given in
 <p>While there are scores of bug fixes, performance improvements, and other
 changes to merge-tracking, the following are the major changes.  See the
-1.7.0 section in the <a
+1.8.0 section in the <a
 file for a complete list.</p>
 <div class="h4" id="subtree-mergeinfo-recording">
-<h4>Reduced subtree mergeinfo changes
+<h4>XXX(1.7) Reduced subtree mergeinfo changes
   <a class="sectionlink" href="#subtree-mergeinfo-recording"
     title="Link to this section">&para;</a>
@@ -976,240 +553,12 @@ mergeinfo.</p>
 </div>  <!-- subtree-mergeinfo-recording -->
-<div class="h4" id="reintegrate-merges">
-<h4>Reintegrate merges are less restrictive
-  <a class="sectionlink" href="#reintegrate-merges"
-    title="Link to this section">&para;</a>
-<p>Reintegrate merges now succeed in the case where all the prior 'sync'
-merges were done as subtree merges, but effectively all the changes were
-merged from the target to the source.  Reintegrate also works with shallow
-targets, as long as none of the excluded subtrees are affected by the
-</div>  <!-- reintegrate-merges -->
-<div class="h4" id="merge-notifications">
-<h4>Improved notification about mergeinfo changes
-  <a class="sectionlink" href="#merge-notifications"
-    title="Link to this section">&para;</a>
-<p>Merge-tracking aware merges now produce special notifications and headers
-when a merge records mergeinfo describing a merge or elides mergeinfo.  This
-clearly differentiates between changes that are made due to application of a
-diff from the merge source and those that are simply merge-tracking
-'housekeeping' changes.</p>
-<p>Below is an example of the new output, showing notifications about
-application of a diff to the file <tt>lib/src/psi.c</tt> and mergeinfo
-changes resulting from this merge.</p>
-   $ svn merge ^/trunk -c3 --depth infinity
-   --- Merging r3 into 'lib':
-   U    lib/src/psi.c
-   --- Recording mergeinfo for merge of r3 into '.':
-    U   .
-   --- Recording mergeinfo for merge of r3 into 'lib':
-    G   lib
-   --- Eliding mergeinfo from 'lib':
-    U   lib 
-</div>  <!-- merge-notifications -->
-<div class="h4" id="merge-mixed-rev-wc">
-<h4>Merges into mixed-revision working copies now disallowed by default
-  <a class="sectionlink" href="#merge-mixed-rev-wc"
-    title="Link to this section">&para;</a>
-<p>To prevent unnecessary conflicts, <tt>svn merge</tt> will now fail
-with an error if the merge target is a
-<a href=""
- >mixed-revision working copy</a>.</p>
-<p>A mixed-revision working copy will need to be updated with
-<tt>svn update</tt> before a merge can be performed into it.
-This restriction has always existed during merges using the
-<strong><tt>--reintegrate</tt></strong> option and it is now the
-behaviour for every type of merge.</p>
-<p>For backwards-compatibility, there is a new option called
-<strong><tt>--allow-mixed-revisions</tt></strong> which disables
-check for a mixed-revision working copy, except for reintegrate merges.
-Using this option is <strong>not</strong> recommended.
-Please use <tt>svn update</tt> instead.</p>
-</div>  <!-- merge-mixed-rev-wc -->
-<div class="h4" id="svn-mergeinfo-enhancements">
-<h4>The mergeinfo subcommand accounts for subtree and partial merges
-  <a class="sectionlink" href="#svn-mergeinfo-enhancements"
-    title="Link to this section">&para;</a>
-<p>The <tt>svn mergeinfo</tt> subcommand now flags revisions wich are
-partially merged to a target with the <tt>'*'</tt> decorator.  A revision
-may be partially merged due to non-inheritable mergeinfo on the target or
-because of explicit mergeinfo on some subtree of the target.  The latter case
-is ignored by default, but may be considered by using the new <tt>--depth
-</tt> and <tt>-R</tt> options for <tt>svn mergeinfo</tt>.</p>
-</div>  <!-- svn-mergeinfo-enhancements -->
-<div class="h4" id="svn-merge-record-only">
-<h4>Transitive record only merges
-  <a class="sectionlink" href="#svn-merge-record-only"
-    title="Link to this section">&para;</a>
-<p>Merges performed with the <tt>--record-only</tt> option now apply
-<tt>svn:mergeinfo</tt> diffs from the merge source.</p>
-</div>  <!-- svn-merge-record-only -->
-<div class="h4" id="svn-merge-sparse-no-tree-conflict">
-<h4>Merges into sparse directories no longer cause tree conflicts
-  <a class="sectionlink" href="#svn-merge-sparse-no-tree-conflict"
-    title="Link to this section">&para;</a>
-<p>Merges into shallow working copies used to cause tree conflicts on nodes
-which were affected by the merge but not present in the working copy.
-In 1.7, no tree conflict is flagged. Instead, non-inheritable subtree mergeinfo
-is created on the parents of missing nodes, so that later merges into working
-copies that are not sparse will pick up any missing changes for those nodes.</p>
-</div>  <!-- svn-merge-sparse-no-tree-conflicts -->
 </div>  <!-- merge-tracking-enhancements -->
-<div class="h3" id="server-performance-tuning">
-<h3>Server-side performance tuning
-  <a class="sectionlink" href="#server-performance-tuning"
-    title="Link to this section">&para;</a>
-<p>Previous releases of Subversion already supported various caching
-mechanism like memcached. In version 1.7, the servers will aggressively
-cache data in-process to maximize performance. To mitigate the network
-throughput as the next potential bottleneck in the chain, the data
-compression rate can be configured as well.</p>
-<div class="h4" id="data-caches">
-<h4>Data caching
-  <a class="sectionlink" href="#data-caches"
-    title="Link to this section">&para;</a>
-<p>Per default, Subversion server processes will use a 16 MB memory
-block to cache file and folder content. This amount is being allocated
-by every server process, i.e. to determine the maximum size of cache
-memory available per process can roughly be estimated by</p>
-cache limit = 0.8 * (RAM size / max. server process count) - 4 MB
-<p>A reasonable upper limit to that in-process cache size is the size
-of the active data set. This is e.g. the size of user files in /trunk
-plus the size of all differing files on active branches. So, two or
-three times the sum of all /trunk sizes or all active projects on that
-server is a reasonable indication for a performance-optimal cache size.
-<p><tt>svnserve</tt> introduces a new <tt>--memory-cache-size</tt>

-/ <tt>-M</tt> command line parameter to override the default cache 
-size. For <tt>mod_dav_svn</tt>, a 10 GB cache configuration in 
-<tt>http.conf</tt> looks like this</p>
-&lt;IfModule dav_svn_module&gt;
-    SVNInMemoryCacheSize 10485760
-<p>As a side-effect, the memory consumption becomes more predictable
-in many usage scenarios since there is less need to gather and pre-process
-data. Please note that a cache size of <tt>0</tt> will deactivate the
-new caching facilities and cause the server to fall back to 1.6 caching
-</div>  <!-- data-caches -->
-<div class="h4" id="compression-level">
-<h4>Network data compression level
-  <a class="sectionlink" href="#compression-level"
-    title="Link to this section">&para;</a>
-<p>Subversion servers are often disk or network I/O limited. With the
-introduction of <a href="#data-caches">data caching</a>, however, disk
-I/O can be widely eliminated and the CPU load created by data
-compression will become a bottleneck on fast network connections.</p>
-<p>The default setting will allow for 10 to 15 MB/s net data throughput
-(5 MB to 10 MB compressed data) per client and per CPU core. On a 
-multi-core server with a 1 Gb network connection or if clients are mainly 
-connected with very limited bandwidth, you may want to select a higher 
-compression rate to squeeze a little more data through the network at 
-the expense of significantly higher server CPU loads. If the server's NIC 
-is not a bottleneck, you may consider lowering the compression level to 
-<tt>1</tt> or <tt>2</tt> for 100 Mb clients and to <tt>0</tt>

-(compression off) for a network with predominately 1 Gb clients.</p>
-<p>To that end, <tt>svnserve</tt> accepts the new optional 
-<tt>--compression</tt> or <tt>-c</tt> command line parameter.
-<tt>mod_dav_svn</tt> supports the feature as well but its impact is
-limited since over HTTP, network data compression is used only in certain
-cases to begin with. The optional module parameter 
-<tt>SVNCompressionLevel</tt> controls it:</p>
-&lt;IfModule dav_svn_module>
-    SVNCompressionLevel 9
-</div>  <!-- compression level -->
-</div>  <!-- server-performance-tuning -->
-<div class="h3" id="diff-optimizations">
-<h3>Optimizations of diff, merge and blame
-  <a class="sectionlink" href="#diff-optimizations"
-    title="Link to this section">&para;</a>
-<p>The svn diff algorithm, which is at the core of <tt>diff</tt>,
-<tt>merge</tt> and <tt>blame</tt>, has been optimized to process
-identical prefix and suffix lines more efficiently. This speeds up those
-operations, especially for large files when the changes are contained in
-a limited part of the files.</p>
-</div>  <!-- diff-optimizations -->
-<div class="h3" id="libmagic-support">
-<h3>Detecting MIME types with libmagic
-  <a class="sectionlink" href="#libmagic-support"
-    title="Link to this section">&para;</a>
-<p>Subversion 1.7 can optionally be compiled with support for
-<a href="">libmagic</a> to detect
-MIME types of binary files which are added to version control.
-This feature is used only for binary files for which no MIME type
-is found via auto-props or the mime-types-file configuration option.</p>
-</div>  <!-- libmagic-support -->
 </div>  <!-- enhancements -->
 <div class="h2" id="distribution-changes">
-<h2>Dependency, license and distribution changes
+<h2>XXX(1.7) Dependency, license and distribution changes
   <a class="sectionlink" href="#distribution-changes"
     title="Link to this section">&para;</a>
@@ -1288,19 +637,19 @@ repository</a>.</p>
 </div>  <!-- distribution-changes -->
-<div class="h2" id="svn-1.5-deprecation">
-<h2>Subversion 1.5.x series no longer supported
-  <a class="sectionlink" href="#svn-1.5-deprecation"
+<div class="h2" id="svn-1.6-deprecation">
+<h2>Subversion 1.6.x series no longer supported
+  <a class="sectionlink" href="#svn-1.6-deprecation"
     title="Link to this section">&para;</a>
-<p>The Subversion 1.5.x line is no longer supported.  This doesn't
-mean that your 1.5 installation is doomed; if it works well and is all
+<p>The Subversion 1.6.x line is no longer supported.  This doesn't
+mean that your 1.6 installation is doomed; if it works well and is all
 you need, that's fine.  "No longer supported" just means we've stopped
-accepting bug reports against 1.5.x versions, and will not make any
-more 1.5.x bugfix releases.</p>
+accepting bug reports against 1.6.x versions, and will not make any
+more 1.6.x bugfix releases.</p>
-</div>  <!-- svn-1.5-deprecation -->
+</div>  <!-- svn-1.6-deprecation -->
 <!-- ***************** END CONTENT ****************** -->
 </div> <!-- #site-content -->

View raw message