subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r898502 - /subversion/site/publish/release-notes/1.6.html
Date Tue, 12 Jan 2010 20:46:47 GMT
Author: cmpilato
Date: Tue Jan 12 20:46:46 2010
New Revision: 898502

Convert 1.6 release notes into our new page format.

      - copied, changed from r898492, subversion/site/publish/TEMPLATE

Copied: subversion/site/publish/release-notes/1.6.html (from r898492, subversion/site/publish/TEMPLATE)
--- subversion/site/publish/TEMPLATE (original)
+++ subversion/site/publish/release-notes/1.6.html Tue Jan 12 20:46:46 2010
@@ -13,9 +13,771 @@
 <div id="site-content">
 <!--#include virtual="/site-notice.html" -->
+<h1>Subversion 1.6 Release Notes</h1>
-                           <!-- PUT CONTENT HERE -->
+<h2 id="news" title="news"
+>What's New in Subversion 1.6</h2>
+  <li><a href="#auth-related-improvements"
+      >Improved handling of authentication data</a></li>
+  <li><a href="#repository-root-relative-urls"
+      >Repository root relative URLs</a></li>
+  <li><a href="#externals"
+      >Improvements to <tt>svn:externals</tt></a></li>
+  <li><a href="#tree-conflicts"
+      >Detection of tree conflicts</a></li>
+  <li><a href="#filesystem-improvements"
+      >Filesystem storage improvements</a></li>
+  <li><a href="#ctypes-python-bindings"
+      >Ctypes Python Bindings</a></li>
+  <li><a href="#improved-interactive-conflict-resolution"
+      >Improved interactive conflict resolution</a></li>
+  <li><a href="#sparse-directory-exclusion"
+      >Sparse directory exclusion</a></li>
+  <li><a href="#svnserve-logging"
+      >Logging support for svnserve</a></li>
+  <li><a href="#historical-uris"
+      >New public HTTP URI syntax for examining history</a></li>
+  <li><a href="#cmdline"
+      >Command-line client improvements</a></li>
+  <li><a href="#apis"
+      >API changes, improvements, and much language bindings work</a></li>
+  <li><a href="#bug-fixes"
+      >More than 65 new bug fixes, enhancements</a></li>
+<p>Subversion 1.6 is a superset of all previous Subversion releases,
+and is considered the current "best" release.  Any feature or bugfix
+in 1.0.x through 1.5.x is also in 1.6, but 1.6 contains features and
+bugfixes not present in any earlier release.  The new features will
+eventually be documented in a 1.6 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.6 section of the <a
+href="" >CHANGES</a>
+<h2 id="compatibility"
+ title="compatibility"
+>Compatibility Concerns</h2>
+<p>Older clients and servers interoperate transparently with 1.6
+servers and clients.  However, some of the new 1.6 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.6 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.6 maintains API/ABI compatibility with earlier
+releases, by only adding new functions, never removing old ones.  A
+program written to the 1.0, 1.1, 1.2, 1.3, 1.4 or 1.5 API can both compile
+and run using 1.6 libraries.  However, a program written for 1.6
+cannot necessarily compile or run against older libraries.</p>
+<h3 id="new-feature-compatibility-table"
+ title="new-feature-compatibility-table"
+>New Feature Compatibility Table</h3>
+<table border="1">
+  <tr>
+    <th>New Feature</th>
+    <th>Minimum Client<sup>1</sup></th>
+    <th>Minimum Server</th>
+    <th>Minimum Repository</th>
+    <th>Notes</th></tr>
+  <tr>
+    <td><a href="#fsfs-packing">FSFS Packing</a></td>
+    <td>any</td>
+    <td>1.6</td>
+    <td>1.6</td>
+    <td></td></tr>
+  <tr>
+    <td><a href="#tree-conflicts">Tree Conflicts</a></td>
+    <td>1.6</td>
+    <td>1.6</td>
+    <td>any</td>
+    <td>Using servers older than 1.6 is possible, but some kinds
+      of conflicts will not be detected.</td></tr>
+   <tr>
+     <td colspan="5"><sup>1</sup>Reminder: when using the <code>file://</code>
+       repository access method, the Subversion program is both the client
+       <em>and</em> the server.</td></tr>
+<h3 id="wc-and-fs-format-change"
+ title="wc-and-fs-format-change"
+>Working Copy and Repository Filesystem Format Changes</h3>
+<p>The working copy format has been upgraded.  This means that 1.5 and
+older Subversion clients will <em>not</em> be able to work with
+working copies produced by Subversion 1.6.  Working copies are <a
+href="#wc-upgrades" >upgraded automatically</a>.</p>
+<p>Similarly, the repository filesystem formats have changed, meaning
+that 1.5 and older versions of Subversion tools that normally access
+a repository directly (e.g. <tt>svnserve</tt>, <tt>mod_dav_svn</tt>,
+<tt>svnadmin</tt>) won't be able to read a repository created by
+Subversion 1.6.  But, repositories are <a href="#repos-upgrades"
+><strong>not</strong> upgraded automatically</a>.</p>
+<h4 id="wc-upgrades"
+ title="wc-upgrades"
+>Working Copy Upgrades</h4>
+<p><strong>WARNING:</strong> if a Subversion 1.6 client encounters a
+pre-1.6 working copy, it will <em>automatically</em> upgrade the
+working copy format as soon as it touches it, making it unreadable by
+older Subversion clients.  If you are using several versions of
+Subversion on your machine, be careful about which version you use in
+which working copy, to avoid accidentally upgrading a working copy.
+(But note that this "auto upgrade" behavior does <em>not</em> occur
+with the <a href="#repos-upgrades" >repositories</a>, only working
+<p>If you accidentally upgrade a 1.5 working copy to 1.6, and wish to
+downgrade back to 1.5, use the <a
+><tt></tt></a> script.  See <a
+>this FAQ entry</a> for details, and run the script with the
+<code>--help</code> option for usage instructions.</p>
+<h4 id="repos-upgrades"
+ title="repos-upgrades"
+>Repository Upgrades</h4>
+<p>The Subversion 1.6 server works with 1.5 and older repositories,
+and it will <em>not</em> upgrade such repositories to 1.6 unless
+specifically requested to via the
+<strong><code>svnadmin&nbsp;upgrade</code></strong> command.
 This means
+that some of the new 1.6 features will not become available simply by
+upgrading your server: you will also have to upgrade your
+repositories.  (We decided not to auto-upgrade repositories because we
+didn't want 1.6 to silently make repositories unusable by
+1.5&nbsp;&mdash;&nbsp;that step should be a conscious decision on the
+part of the repository admin.)</p>
+<h3 id="output-changes"
+ title="output-changes"
+>Command Line Output Changes</h3>
+<p>Although we try hard to keep output from the command line programs
+compatible between releases, new information sometimes has to be
+added.  This can break scripts that rely on the exact format of the
+<h4 id="proplist-verbose"
+ title="proplist-verbose"
+>Improved output of <code>svn proplist --verbose</code></h4>
+<p>The output of <code>svn proplist --verbose</code> has been
+improved, and <code>svn propget</code> now accepts the <code>--verbose</code>
+option.  The following example illustrates these changes.</p>
+   $ svn proplist --verbose build.conf
+   Properties on 'build.conf':
+     svn:eol-style
+       native
+     svn:mergeinfo
+       /trunk/build.conf:1-4800
+       /branches/a/build.conf:3000-3400
+       /branches/b/build.conf:3200-3600
+   $ 
+<h4 id="svn-status"
+ title="svn-status"
+>Changed output of <code>svn status</code></h4>
+<p>The output of <code>svn status</code> contains the additional seventh
+column which informs whether the item is the victim of a tree conflict.
+An additional line with more detailed description of a tree conflict is
+displayed after each item remaining in tree conflict.</p>
+   $ svn status
+   M
+   A     C src/error.c
+         >   local add, incoming add upon update
+   M       src/log.c
+   M     C src/path.c
+         >   local edit, incoming delete upon update
+   D     C src/properties.c
+         >   local delete, incoming edit upon merge
+   M     C src/time.c
+   $ 
+<h4 id="conflict-summary"
+ title="conflict-summary"
+>Conflict summary printed by <code>svn update</code> and <code>svn merge</code></h4>
+<code>svn update</code> and <code>svn merge</code> now print
+a summary of conflicts upon completion.
+$ svn update --accept=postpone
+   C alpha
+ C   beta
+C    gamma
+Updated to revision 3.
+Summary of conflicts:
+  Text conflicts: 1
+  Property conflicts: 1
+  Tree conflicts: 1
+Minor problems with the conflict summary are described in
+<em><a href="/issues/show_bug.cgi?id=3342">issue 3342</a></em>.
+<h3 id="hook-changes"
+ title="hook-changes"
+>Hook Changes</h3>
+<h4 id="pre-lock-hook-output"
+ title="pre-lock-hook-output"
+>Changed handling of output of <code>pre-lock</code> hook</h4>
+<p>The output of <code>pre-lock</code> hook was previously discarded, but
+it is used to specify the names of lock tokens.</p>
+<h2 id="new-features"
+ title="new-features"
+>New Features</h2>
+<h3 id="auth-related-improvements"
+ title="auth-related-improvements"
+>Improved handling of authentication data (<em>client</em>)</h3>
+<p><!-- XXX --><em>This section is currently incomplete, please
+help write it!</em></p>
+<h4 id="auth-related-improvements-plaintext-passwords"
+>Prompting before storing passwords in plaintext form</h4>
+<p>Subversion prompts before storing passwords in plaintext form.</p>
+   $ svn checkout repository_trunk
+   Authentication realm: &lt;; Example
+   Password for 'user':
+   -----------------------------------------------------------------------
+   ATTENTION!  Your password for authentication realm:
+      &lt;; Example
+   can only be stored to disk unencrypted!  You are advised to configure
+   your system so that Subversion can store passwords encrypted, if
+   possible.  See the documentation for details.
+   You can avoid future appearances of this warning by setting the value
+   of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
+   '/home/user/.subversion/servers'.
+   -----------------------------------------------------------------------
+   Store password unencrypted (yes/no)?
+<h4 id="auth-related-improvements-kwallet-gnome-keyring"
+>Support for storing passwords in KWallet and GNOME Keyring (Unix-like systems)</h4>
+<p>Passwords can be stored in KWallet (KDE 4) and GNOME Keyring.</p>
+<h4 id="auth-related-improvements-ssl-client-certificate-passphrases"
+>Support for storing SSL client certificate passphrases</h4>
+<p>SSL client certificate passphrases can be stored in KWallet, GNOME
+Keyring, Mac OS Keychain, a Windows CryptoAPI encrypted form or in plaintext form.</p>
+<h3 id="repository-root-relative-urls"
+ title="repository-root-relative-urls"
+>Repository root relative URLs (<em>client</em>)</h3>
+<p><!-- XXX --><em>This section is currently incomplete, please
+help write it!</em>  See the
+<a href="">design
notes</a> for more information.</p>
+   $ svn SUBCOMMAND ^/
+<h3 id="externals"
+ title="externals"
+>Improvements to <tt>svn:externals</tt></h3>
+<p>Subversion 1.6 adds a couple of new features for users of
+<tt>svn:externals</tt>.  The include:</p>
+  <li><a href="#file-externals"
+      >Support for files in <tt>svn:externals</tt></a></li>
+  <li><a href="#shell-quoting-externals"
+      >Support usual shell quoting rules in externals definitions</a></li>
+<h4 id="file-externals"
+ title="file-externals"
+>Support for files in <tt>svn:externals</tt>
+    (<em>client</em>)</h4>
+  If the URL in a <tt>svn:externals</tt> description refers to a file,
+  it will be added into the working copy as a versioned item.
+  There are a few differences between directory and file
+  externals.
+  <li>
+    The path to the file external must be in a working copy that is
+    already checked out.  While directory externals can place the
+    external directory at any depth and it will create any
+    intermediate directories, file externals must be placed into a
+    working copy that is already checked out.
+  </li>
+  <li>
+    The file external's URL must be in the same repository as the URL
+    that the file external will be inserted into; inter-repository
+    file externals are not supported.
+  </li>
+  <li>
+    While commits do not descend into a directory external, a commit
+    in a directory containing a file external will commit any
+    modifications to the file external.
+  </li>
+<p>The differences between a normal versioned file and a file
+  <li>
+    File externals cannot be moved or deleted; the
+    <tt>svn:externals</tt> property must be modified instead; however,
+    file externals can be copied.
+  </li>
+<p>Other facts.</p>
+  <li>
+    A file external shows up as a <tt>X</tt> in the switched status
+    column.
+  </li>
+<h4 id="shell-quoting-externals"
+ title="shell-quoting-externals"
+>Support usual shell quoting rules in externals definitions
+  (<em><a href="/issues/show_bug.cgi?id=2461">issue 2461</a></em>,
+<p><!-- XXX -->Need to document possible incompatibilities (see
+<a href="/ds/;dsMessageId=86142">this
+<h4 id="file-externals-further-reading"
+ title="file-externals-further-reading"
+>Further reading</h4>
+<p>See The <a
+>svn:externals</a> section of the Subversion Book.</p>
+<h3 id="tree-conflicts"
+ title="tree-conflicts"
+>Detection of tree conflicts (<em>client</em>)</h3>
+<p>Subversion 1.6 recognizes a new kind of conflict, known as a
+&quot;tree conflict&quot;. Such conflicts manifest at the level
+of directory structure, rather than file content.</p>
+<p>Situations now flagged as conflicts include deletions of locally
+modified files, and incoming edits to locally deleted files. Files
+and directories which are victims of a tree conflict cannot be
+committed before the conflict is marked resolved.</p>
+<p>Note that Subversion is still treating renames as a &quot;copy+delete&quot;
+operation, so file renames causing tree conflicts can only be detected
+in terms of file additions and deletions. Because of this, false positives
+during tree conflict detection are possible.</p>
+<p>To facilitate tree conflict detection, attempting to commit the
+deletion of a file which has already been deleted in the HEAD revision
+now causes an error. In Subversion 1.5, this was treated as a no-op,
+potentially resulting in &quot;empty&quot; revisions which contained
+no changes.</p>
+<h4 id="tree-conflicts-further-reading" 
+ title="tree-conflicts-further-reading"
+>Further reading</h4>
+<p>See the <a
+>tree conflicts</a> section of the Subversion Book.</p>
+<h3 id="filesystem-improvements"
+ title="filesystem-improvements"
+>Filesystem Storage Improvements</h3>
+<p>Subversion 1.6 contains several improvements to both the Berkeley DB and FSFS
+backends.  These are designed to improve storage space, and can result in
+drastically smaller repositories.  These changes include:</p>
+  <li><a href="#rep-sharing"
+      >Representation sharing</a></li>
+  <li><a href="#fsfs-packing"
+      >FSFS inode packing</a></li>
+  <li><a href="#fsfs-memcached"
+      >FSFS repositories: Support for Memcached</a></li>
+  <li><a href="#bdb-forward-deltas"
+      >BDB repositories: Forward deltas</a></li>
+<h4 id="rep-sharing"
+ title="rep-sharing"
+>Sharing multiple common representations
+  (<em><a href="/issues/show_bug.cgi?id=2286">issue 2286</a></em>,
+   <em>server</em>)</h4>
+<p>When using many branches and merging between them often, it is common to
+have files with similar lines of history which contain the exact same content.
+In the past, Subversion has stored these files as deltas against previous
+versions of the file.  Subversion 1.6 will now use existing representations in
+the filesystem for duplicate storage.  Depending on the size of the repository,
+and the degree of branching and merging, this can cause an up to 20% space
+reduction for Berkeley DB repositories and a 15% reduction for FSFS
+<h4 id="fsfs-packing"
+ title="fsfs-packing"
+>FSFS repositories: Packing completed shards (<em>server</em>)</h4>
+<p>Subversion 1.5 introduced the ability for FSFS repositories to be
+<em><a href="svn_1.5_releasenotes.html#fsfs-sharding">sharded</a></em>
+multiple directories for revision and revprop files.  Subversion 1.6 takes
+the sharding concept further, and allows full shard directories to be
+<em>packed</em> into a single file.  By reducing internal fragmentation in
+the filesystem, packed FSFS repositories have significant space savings
+over their unpacked counterparts, especially repositories which contain
+many small commits.  Using a one-file-per-shard approach also allows
+Subversion to reduce disk I/O and better exploit operating system caches.
+<p>To pack a repository, run <code>svnadmin pack</code> on the repository.
+Once a repository has been packed, there is no migration path back to an
+unpacked state, and it can only be read by Subversion 1.6 or greater
+<h4 id="fsfs-memcached"
+ title="fsfs-memcached"
+>FSFS repositories: Support for Memcached (<em>server</em>)</h4>
+<p><!-- XXX --><a href="">Memcached</a>
+cache data of FSFS repositories.</p>
+<p>Additional build-time dependencies: APR-Util &ge;1.3 || ( APR-Util &lt;
+1.3 &amp;&amp; APR_Memcache )</p>
+<h4 id="bdb-forward-deltas"
+ title="bdb-forward-deltas"
+>BDB repositories: Forward deltas (<em>server</em>)</h4>
+<p>Newly created BDB repositories now use forward deltas instead of reverse
+deltas. <code>svnadmin upgrade</code> can be used to make older repositories
+use forward deltas for new revisions. If you want to achieve the most
+optimized state of an older repository, you still need to perform dump and
+load of the repository.</p>
+<h3 id="ctypes-python-bindings"
+ title="ctypes-python-bindings"
+>Ctypes Python Bindings</h3>
+<p>Subversion 1.6 introduces a new python binding for the Subversion API. The
+new binding makes use of the ctypes library to present the standard API along
+with a selection of Python classes to give an object-oriented interface to
+standard Subversion constructs.  These bindings have several advantages over
+the traditional SWIG-based bindings:</p>
+  <li>Generated automatically</li>
+  <li>Straightforward, and don't have any special "transformation" rules</li>
+  <li>Pure python and cross-platform</li>
+  <li>Both forward and backward compatible as long as the functions used in the programs
+  have compatible definitions</li>
+  <li>High level classes make it easy to access common subversion
+  functionality in a pythonic way</li>
+<p>Building the ctypes bindings produces two ways to access Subversion from
+python. The first interface is a direct python port of the standard API.
+Ctypes provides some basic type conversions and allows the calling of
+Subversion functions just like in C code. The new bindings also introduce a
+set of python classes to enable higher-level access to Subversion features.
+These classes take full advantage of python features and hide as much of the
+C implementation as possible to make Subversion easier to use for python
+programmers not familiar with the C API.</p>
+<h2 id="enhancements"
+ title="enhancements"
+>Enhancements and Bugfixes</h2>
+<h3 id="improved-interactive-conflict-resolution"
+ title="improved-interactive-conflict-resolution"
+>Improved interactive conflict resolution (<em>client</em>)</h3>
+<p>Interactive conflict resolution supports new <code>display-conflict</code>,
+<code>mine-conflict</code> and <code>theirs-conflict</code> options.</p>
+<p>Here's an example using the command-line client:</p>
+   $ svn up
+   U
+   Conflict discovered in ''.
+   Select: (p) postpone, (df) diff-full, (e) edit,
+           (mc) mine-conflict, (tc) theirs-conflict,
+           (s) show all options: s
+     (e)  edit             - change merged file in an editor
+     (df) diff-full        - show all changes made to merged file
+     (r)  resolved         - accept merged version of file
+     (dc) display-conflict - show all conflicts (ignoring merged version)
+     (mc) mine-conflict    - accept my version for all conflicts (same)
+     (tc) theirs-conflict  - accept their version for all conflicts (same)
+     (mf) mine-full        - accept my version of entire file (even non-conflicts)
+     (tf) theirs-full      - accept their version of entire file (same)
+     (p)  postpone         - mark the conflict to be resolved later
+     (l)  launch           - launch external tool to resolve conflict
+     (s)  show all         - show this list
+   Select: (p) postpone, (df) diff-full, (e) edit,
+           (mc) mine-conflict, (tc) theirs-conflict,
+           (s) show all options: mc
+   G
+   Updated to revision 36666.
+   $ 
+<h3 id="sparse-directory-exclusion"
+ title="sparse-directory-exclusion"
+>Sparse directory exclusion</h3>
+<p>In Subversion 1.6, the <code>--set-depth</code> parameter to <code>svn
+update</code> has grown a new value&mdash;<em>exclude</em>. This value
+Subversion to exclude the target from the working copy, immediately and until
+further notice. Prior to Subversion 1.6, if a directory could not easily be
+removed from a working copy.  If it was deleted without the help of Subversion,
+it would return on the next <code>svn update</code>.  If it was deleted with
+<code>svn delete</code>, the directory remained as a local modification
+forever. (Unless, of course, it was accidentally committed.)  The new exclusion
+mechanism in Subversion 1.6 fixes both these problems.</p>
+<p>Note that if you exclude a versioned directory that has some unversioned
+files in it, or some files with local modifications, Subversion handles this
+situation gracefully. All the files that aren't safe to delete, Subversion
+leaves around, and of course leaves any intermediate directories required to
+reach those files, too.</p>
+<h4 id="sparse-directory-exclusion-further-reading"
+ title="sparse-directory-exclusion-further-reading"
+>Further reading</h4>
+<p>See this <a href="">blog
post</a> for more examples and information.</p>
+<h3 id="svnserve-logging"
+ title="svnserve-logging"
+>Logging support for svnserve (<em>server</em>)</h3>
+<p><code>svnserve</code> now accepts the <code>--log-file</code>
option which
+allows to specify the file used for logging.</p>
+<h3 id="historical-uris"
+ title="historical-uris"
+>New public 'historical' HTTP URI syntax for mod_dav_svn (<em>server</em>)</h3>
+<p>mod_dav_svn now supports a new public URI syntax for
+examining older versions of files or directories.  The intent here is
+to allow users to examine history without the use of an svn client,
+and to make it easier for 3rd-party tools (e.g. code-review services)
+to work directly against repositories without using svn libraries.</p>
+    <pre>http://host/repos/path?[p=PEG][&amp;r=REV]</pre>
+<p>The new syntax works similarly to the way URIs work with the svn
+  commandline client.  Simply requesting <b>http://host/repos/path</b>
+  fetches "path" in the HEAD revision.  Adding a "p" query argument
+  specifies a different peg revision instead, so that:</p>
+    <pre>http://host/repos/path?p=38</pre>
+<p> similar to specifying "path@38" on the commandline.  Adding a
+  "r" query argument is like specifying "-r" on the commandline,
+  causing the repository to follow history backwards from the peg
+  revision to the older operative revision:</p>
+    <pre>http://host/repos/path?p=38&amp;r=20</pre>
+<p>As with the commandline, the peg revision defaults to HEAD if
+  unspecified, and the operative revision defaults to the peg
+  revision.  The online Subversion Book has
+  a <a href="">section
+  explaining peg and operative revisions</a> in great detail.</p>
+<h3 id="cmdline"
+ title="cmdline"
+>Command-line client improvements (<em>client</em>)</h3>
+<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.6.0 section in the <a
+href="">CHANGES</a> file
+for a complete list.</p>
+<h4 id="log-multiple-args"
+ title="log-multiple-args"
+>log can take multiple revisions</h4>
+<p>The <code>svn log</code> command can now take multiple revision arguments
+in one invocation.  Both the -c and -r arguments are supported.</p>
+   $ svn log -r36169 -r36171
+   ------------------------------------------------------------------------
+   r36169 | sussman | 2009-02-26 14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line
+   ...log message omitted...
+   ------------------------------------------------------------------------
+   r36171 | joeswatosh | 2009-02-26 22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines
+   ...log message omitted...
+   $ svn log -c36169,36171
+   ------------------------------------------------------------------------
+   r36169 | sussman | 2009-02-26 14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line
+   ...log message omitted...
+   ------------------------------------------------------------------------
+   r36171 | joeswatosh | 2009-02-26 22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines
+   ...log message omitted...
+<h4 id="trust-server-cert"
+ title="trust-server-cert"
+>--trust-server-cert option</h4>
+<p>Option added to <code>svn</code> and <code>svnsync</code>,
so that
+non-interactive operations can work with self-signed certificates not
+backed by a known trust authority.</p>
+with this option:
+   $ svn log -r36364 --trust-server-cert --non-interactive
+   ------------------------------------------------------------------------
+   r36364 | stylesen | 2009-03-06 13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines
+   ...log message omitted...
+   ------------------------------------------------------------------------
+without this option:
+   $ svn log -r36364 
+   Error validating server certificate for '':
+    - The certificate is not issued by a trusted authority. Use the
+      fingerprint to validate the certificate manually!
+   Certificate information:
+    - Hostname:
+    - Valid: from Sep 24 22:01:07 2007 GMT until Sep 23 22:01:07 2011 GMT
+    - Issuer: sv, CollabNet, Brisbane, California, US
+   (
+    - Fingerprint:
+   AA:5B:74:B1:E2:7F:38:B3:2B:C2:B1:60:6E:01:BB:F5:7C:37:98:46
+   (R)eject, accept (t)emporarily or accept (p)ermanently? t
+   ------------------------------------------------------------------------
+   r36364 | stylesen | 2009-03-06 13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines
+   ...log message omitted...
+   ------------------------------------------------------------------------
+<h3 id="apis"
+ title="apis"
+>API changes, improvements and language bindings (<em>client and server</em>)</h3>
+<p>The <tt>pre-lock</tt> hook can now specify the lock-token string
+via the hook's stdout; see <a
+>r32778</a> for details.  Note that when the hook uses this feature,
+it must take responsibility for ensuring that lock tokens are unique
+across the repository.</p>
+<p>There are too many new and revised APIs in Subversion 1.6.0 to list
+them all here.  See the <a
+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
+what's changed.</p>
+<p>One general change is that most APIs that formerly took a
+<tt>recurse</tt> parameter have been upgraded to accept a
+<tt>depth</tt> parameter instead, to enable the new <a
+href="#sparse-checkouts">sparse checkouts</a> feature.</p>
+<p>Language bindings have mostly been updated for the new APIs, though
+some may lag more than others.</p>
+<h3 id="bug-fixes"
+ title="bug-fixes"
+>Bug fixes (<em>client and server</em>)</h3>
+<p>A great many bugs have been fixed.  See the 1.6.0 section in the <a
+href="">CHANGES</a> file
+for details.</p>
+<h2 id="svn-1.4-deprecation"
+ title="svn-1.4-deprecation"
+>Subversion 1.4.x series no longer supported</h2>
+<p>The Subversion 1.4.x line is no longer supported.  This doesn't
+mean that your 1.4 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.4.x versions, and will not make any
+more 1.4.x bugfix releases, except perhaps for absolutely critical
+security or data-loss bugs.</p>
+<h2 id="sqlite"
+ title="sqlite"
+>New Dependency: SQLite</h2>
+<p>We now require <a href="">SQLite</a> to build
+the server and client.  We recommend 3.6.13 or greater, but work with
+anything better than 3.4.0.  Subversion will attempt to use an SQLite
+<a href="">amalgamation</a> if it is
+present in the root of the distribution tarball, otherwise, Subversion will
+search for SQLite in the usual places on the system.  You may also pass
+<code>--with-sqlite</code> to <code>configure</code> to specify the
+of the SQLite library or amalgamation you wish to use.</p>
 </div> <!-- #site-content -->

View raw message