You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by cm...@apache.org on 2010/01/12 21:46:47 UTC
svn commit: r898502 - /subversion/site/publish/release-notes/1.6.html
Author: cmpilato
Date: Tue Jan 12 20:46:46 2010
New Revision: 898502
URL: http://svn.apache.org/viewvc?rev=898502&view=rev
Log:
Convert 1.6 release notes into our new page format.
Added:
subversion/site/publish/release-notes/1.6.html
- copied, changed from r898492, subversion/site/publish/TEMPLATE
Copied: subversion/site/publish/release-notes/1.6.html (from r898492, subversion/site/publish/TEMPLATE)
URL: http://svn.apache.org/viewvc/subversion/site/publish/release-notes/1.6.html?p2=subversion/site/publish/release-notes/1.6.html&p1=subversion/site/publish/TEMPLATE&r1=898492&r2=898502&rev=898502&view=diff
==============================================================================
--- 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>
+<ul>
+ <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>
+</ul>
+
+<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="http://svnbook.red-bean.com" >svnbook.red-bean.com</a>).</p>
+
+<p>This page describes only major changes. For a complete list of
+changes, see the 1.6 section of the <a
+href="http://svn.collab.net/repos/svn/trunk/CHANGES" >CHANGES</a>
+file.</p>
+
+<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>
+</table>
+
+<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
+copies.)</p>
+
+<p>If you accidentally upgrade a 1.5 working copy to 1.6, and wish to
+downgrade back to 1.5, use the <a
+href="http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py"
+><tt>change-svn-wc-format.py</tt></a> script. See <a
+href="http://subversion.tigris.org/faq.html#working-copy-format-change"
+>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 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 — 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
+output.</p>
+
+<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>
+
+<pre>
+ $ 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
+ $
+</pre>
+
+<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>
+
+<pre>
+ $ svn status
+ M Makefile.in
+ 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
+ $
+</pre>
+
+<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.
+
+<pre>
+$ 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
+</pre>
+
+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 now
+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"
+title="auth-related-improvements-plaintext-passwords"
+>Prompting before storing passwords in plaintext form</h4>
+
+<p>Subversion prompts before storing passwords in plaintext form.</p>
+
+<p>Example:</p>
+
+<pre>
+ $ svn checkout https://www.example.com/repository/trunk repository_trunk
+ Authentication realm: <https://www.example.com> Example
+ Password for 'user':
+ -----------------------------------------------------------------------
+ ATTENTION! Your password for authentication realm:
+
+ <https://www.example.com> 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)?
+</pre>
+
+<h4 id="auth-related-improvements-kwallet-gnome-keyring"
+title="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"
+title="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="http://svn.collab.net/repos/svn/trunk/notes/cli-repo-root-relative-support.txt">design notes</a> for more information.</p>
+
+<pre>
+ $ svn SUBCOMMAND ^/
+ $ svn SUBCOMMAND ^/PATH
+</pre>
+
+<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>
+
+<ul>
+ <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>
+</ul>
+
+<h4 id="file-externals"
+ title="file-externals"
+>Support for files in <tt>svn:externals</tt>
+ (<em>client</em>)</h4>
+
+<p>
+ 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.
+</p>
+
+<p>
+ There are a few differences between directory and file
+ externals.
+</p>
+
+<ul>
+ <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>
+</ul>
+
+<p>The differences between a normal versioned file and a file
+external.</p>
+
+<ul>
+ <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>
+</ul>
+
+<p>Other facts.</p>
+
+<ul>
+ <li>
+ A file external shows up as a <tt>X</tt> in the switched status
+ column.
+ </li>
+</ul>
+
+<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>, client)</h4>
+
+<p><!-- XXX -->Need to document possible incompatibilities (see
+<a href="/ds/viewMessage.do?dsForumId=462&dsMessageId=86142">this
+thread</a>)</p>
+
+<h4 id="file-externals-further-reading"
+ title="file-externals-further-reading"
+>Further reading</h4>
+
+<p>See The <a
+href="http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html"
+>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
+"tree conflict". 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 "copy+delete"
+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 "empty" revisions which contained
+no changes.</p>
+
+<h4 id="tree-conflicts-further-reading"
+ title="tree-conflicts-further-reading"
+>Further reading</h4>
+
+<p>See the <a
+href="http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html"
+>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>
+<ul>
+ <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>
+</ul>
+
+<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
+repositories.</p>
+
+<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> into
+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>
+
+<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
+servers.</p>
+
+<h4 id="fsfs-memcached"
+ title="fsfs-memcached"
+>FSFS repositories: Support for Memcached (<em>server</em>)</h4>
+
+<p><!-- XXX --><a href="http://www.danga.com/memcached/">Memcached</a> can
+cache data of FSFS repositories.</p>
+
+<p>Additional build-time dependencies: APR-Util ≥1.3 || ( APR-Util <
+1.3 && 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>
+<ul>
+ <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>
+</ul>
+
+<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>
+
+<pre>
+ $ svn up
+ U Makefile.in
+ Conflict discovered in 'configure.ac'.
+ 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 configure.ac
+ Updated to revision 36666.
+ $
+</pre>
+
+<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—<em>exclude</em>. This value tells
+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="http://blogs.open.collab.net/svn/2009/03/sparse-directories-now-with-exclusion.html">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][&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>...is 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&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="http://svnbook.red-bean.com/en/1.5/svn.advanced.pegrevs.html">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="http://svn.collab.net/repos/svn/trunk/CHANGES">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>
+
+<pre>
+ $ svn log -r36169 -r36171 http://svn.collab.net/repos/svn/
+ ------------------------------------------------------------------------
+ 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 http://svn.collab.net/repos/svn/
+ ------------------------------------------------------------------------
+ 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...
+</pre>
+
+<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:
+<pre>
+ $ svn log -r36364 https://svn.collab.net/repos/svn/trunk --trust-server-cert --non-interactive
+ ------------------------------------------------------------------------
+ r36364 | stylesen | 2009-03-06 13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines
+
+ ...log message omitted...
+ ------------------------------------------------------------------------
+</pre>
+
+without this option:
+<pre>
+ $ svn log -r36364 https://svn.collab.net/repos/svn/trunk
+ Error validating server certificate for 'https://svn.collab.net':
+ - The certificate is not issued by a trusted authority. Use the
+ fingerprint to validate the certificate manually!
+ Certificate information:
+ - Hostname: svn.collab.net
+ - Valid: from Sep 24 22:01:07 2007 GMT until Sep 23 22:01:07 2011 GMT
+ - Issuer: sv, CollabNet, Brisbane, California, US
+ (hostname@collab.net)
+ - 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...
+ ------------------------------------------------------------------------
+</pre>
+
+<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
+href="http://svn.collab.net/viewcvs/svn?rev=32778&view=rev"
+>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="http://svn.collab.net/svn-doxygen/" >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="http://svn.collab.net/repos/svn/trunk/CHANGES">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="http://www.sqlite.org/">SQLite</a> to build both
+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="http://www.sqlite.org/amalgamation.html">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 location
+of the SQLite library or amalgamation you wish to use.</p>
</div> <!-- #site-content -->
</body>