svn_1.3_releasenotes.html [plain text]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style type="text/css"> /* <![CDATA[ */
@import "branding/css/tigris.css";
@import "branding/css/inst.css";
/* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
href="branding/css/print.css"/>
<script type="text/javascript" src="branding/scripts/tigris.js"></script>
<title>Subversion 1.3 Release Notes</title>
</head>
<body>
<div class="app">
<h1 style="text-align: center">Subversion 1.3 Release Notes</h1>
<div class="h2" id="news" title="news">
<h2>What's New in Subversion 1.3</h2>
<ul>
<li>Path-based authorization for svnserve</li>
<li>Improved logging and repository listing in mod_dav_svn</li>
<li>Hugely improved python and ruby bindings</li>
<li>A handful of new commandline switches</li>
<li>Some client and server performance improvements</li>
<li>Many improved APIs</li>
<li>More than 30 new bugfixes</li>
</ul>
<p>Details are described below.</p>
<p>Subversion 1.3 is a superset of all previous Subversion releases.
Anything in 1.0.x, 1.1.x, or 1.2.x is also in 1.3, but 1.3 contains
features and bugfixes not present in any earlier release. The new
features will eventually be documented in a 1.3 version of the free
Subversion book, see
<a href="http://svnbook.red-bean.com">svnbook.red-bean.com</a>.</p>
</div> <!-- news -->
<div class="h2" id="downloading" title="downloading">
<h2>Downloading</h2>
<p>Subversion 1.3 is available as source code in three formats:</p>
<ul>
<li><a href="http://subversion.tigris.org/downloads/subversion-1.3.2.tar.gz">subversion-1.3.2.tar.gz</a></li>
<li><a href="http://subversion.tigris.org/downloads/subversion-1.3.2.tar.bz2">subversion-1.3.2.tar.bz2</a></li>
<li><a href="http://subversion.tigris.org/downloads/subversion-1.3.2.zip">subversion-1.3.2.zip</a> (Windows)</li>
</ul>
<p>For binary packages, please see <a
href="getting.html#binary-packages">the binary package
list</a>. Note that binary packages usually come out about a week
after the corresponding source release. The package maintainers are
volunteers, so please don't harass them — they know
when a new source release has come out, and they work as fast as they
can to make binaries available.</p>
<p>For other Subversion releases, see <a
href="http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=260&expandFolder=74">this folder</a>.</p>
</div> <!-- downloading -->
<div class="h2" id="compatibility" title="compatibility">
<h2>Compatibility Concerns</h2>
<p>Older clients and servers interoperate transparently with 1.3
servers and clients. Of course, some of the new 1.3 features may not
be available unless both client and server are the latest version.
There is <strong>no need</strong> to upgrade your repositories;
Subversion 1.3 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. (<em>WARNING:</em> if you're
using Berkeley DB repositories, installing a new binary distribution
of Subversion may force you to upgrade Berkeley DB as well, see
<a href="#bdb-upgrade">Unexpected Berkeley DB Upgrades</a> below.)</p>
<p>Subversion 1.3 maintains API/ABI compatibility with earlier
releases, by only adding new functions. A program written to the 1.0,
1.1, or 1.2 API can both compile and run using 1.3 libraries.
However, a program written for 1.3 cannot necessarily compile or run
against older libraries.</p>
<div class="h3" id="output-changes" title="output-changes">
<h3>Command Line Output Changes</h3>
<p>Although the Subversion developers try hard to keep output from the
command line programs compatible between releases, new information
sometimes has to be added. This might break scripts that rely on the
exact format of the output. In 1.3, the following changes have been
made to the output:</p>
<ul>
<li><p>'svnlook diff' always diffs added files by default now,
and the new '--diff-copy-from' option causes those diffs
to be against the copyfrom source instead of against an empty
file (for consistency with 'svn diff'). Also, when
diffing against the empty file, the diff headers now say
"revision 0" instead of the copyfrom revision (again for
consistency with 'svn diff').</p></li>
<li><p>'svn diff' output is now in native encoding,
instead of in UTF8.</p></li>
<li><p>Merge conflict markers are now in the encoding of the user's
locale. (Not exactly a command line output change, but near
enough).</p></li>
<li><p>'svn ls --verbose' now shows remote locks as '<tt>O</tt>', just
like 'svn status -u' does.</p></li>
</ul>
</div> <!-- output-changes -->
<div class="h3" id="bdb-upgrade" title="bdb-upgrade">
<h3>Unexpected Berkeley DB Upgrades</h3>
<p>This is not actually related to the Subversion 1.3 release, but it
may affect you if you upgrade to 1.3 via a package distribution
system.</p>
<p>A lot of operating systems now ship Berkeley DB 4.3. Sometimes the
system Berkeley DB libraries can be unintentionally upgraded to 4.3 as
part of some other change pulled down via an OS package delivery
mechanism — for example, upgrading one's Subversion
package. If this happens to you, you will need
to <a href="faq.html#bdb43-upgrade">upgrade existing BerkeleyDB-based
repositories to 4.3.</a></p>
<p>Since Subversion 1.2, the <a
href="http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91"
>Windows binary distributions</a> of Subversion from Branko Čibej
use Berkeley DB 4.3. If you are upgrading from an older version, the
above may be of concern to you.</p>
</div> <!-- bdb-upgrade -->
</div> <!-- compatibility -->
<div class="h2" id="new-features" title="new-features">
<h2>New Features</h2>
<div class="h3" id="svnserve-authz" title="svnserve-authz">
<h3>Path-based authorization for svnserve (<em>requires new server</em>)</h3>
<p><b>svnserve</b>, the stand-alone Subversion server, is now able to
restrict both read and write access using the same
authorization-policy files used by <b>mod_authz_svn</b>. (Previously,
the most one could do with svnserve was restrict write-access via
pre-commit hook scripts.)</p>
<p>The authorization file format is the same
one <a
href="http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.2"
>described here</a>, in Chapter 6 of the Subversion book. You simply
need to point to it from your repository's <em>svnserve.conf</em>
file using the new <tt>authz-db</tt> directive:</p>
<pre>
[general]
password-db = userfile
realm = my realm
anon-access = none
auth-access = write
authz-db = authzfile
</pre>
<p>Note that when the <tt>authz-db</tt> directive is in use, the
"blanket" access directives (<tt>anon-access</tt>
and <tt>auth-access</tt>) can still be in effect too. In order to
access a path, <em>both</em> the "blanket" directives and per-path
authz file must allow access.</p>
</div> <!-- svnserve-authz -->
<div class="h3" id="dav-logging" title="dav-logging">
<h3>Operational logging for mod_dav_svn (<em>requires new server</em>)</h3>
<p>The Apache HTTPD-based server (mod_dav_svn) is now able to log
high-level Subversion operations, e.g., "update", "lock", "commit",
etc. This is an improvement over trying to read and understand the
mysterious chains of WebDAV methods currently listed in
httpd's <em>accesslog</em> file.</p>
<p>To activate this new feature, you need to make use of httpd 2.0's
built in logging directives such
as <a href="http://httpd.apache.org/docs/2.0/logs.html">LogFormat and
CustomLog</a> directives. These directives allow you to flexibly
define your own log formats. All you need to know is that mod_dav_svn
now sets an environment variable named SVN-ACTION whenever it feels
that an http request has completed a particular subversion-related
action. So, for example, the following <em>httpd.conf</em> directive
would log all subversion-related actions to a private logfile, along
with timestamp and username:</p>
<pre>CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION</pre>
<p>Equivalent functionality is planned for svnserve, the standalone
server, but not until Subversion 1.4, because the implementation
strategy there will be a bit different.
See <a
href="http://subversion.tigris.org/issues/show_bug.cgi?id=2409"
>Issue #2409</a> for details.</p>
</div> <!-- dav-logging -->
<div class="h3" id="bindings-improvements" title="bindings-improvements">
<h3>Major Language Binding Improvements</h3>
<ul>
<li>It's now possible to build the SWIG bindings from source without
installing SWIG, because we now bundle the generated output of SWIG
with the release tarball.</li>
<li>The Python and Ruby bindings now support automatic memory management.
If you don't supply Subversion API functions with memory pools,
Subversion will automatically manage its own memory.</li>
<li>The Python and Ruby bindings are now more stable, as verified
by our expanded test suites.</li>
<li>The Ruby bindings now offer complete coverage of the Subversion
APIs.</li>
</ul>
</div> <!-- bindings-improvements -->
<div class="h3" id="new-switches" title="new-switches">
<h3>New subcommand switches</h3>
<dl>
<dt><tt>svn blame --xml [--incremental]</tt></dt>
<dt><tt>svn status --xml [--incremental]</tt></dt>
<dt><tt>svn info --xml [--incremental]</tt></dt>
<dd>Display output in XML. If <tt>--incremental</tt> is also
used, then output XML suitable for concatenation.</dd>
<dt><tt>svn add --no-ignore</tt></dt>
<dt><tt>svn import --no-ignore</tt></dt>
<dd>Disregard all "ignored" file patterns.</dd>
<dt><tt>svnlook tree --full-paths</tt></dt>
<dd>Show full paths instead of indented ones.</dd>
<dt><tt>svnlook diff --diff-copy-from</tt></dt>
<dd>Print differences against copy source.</dd>
<dt><tt>svnlook changed --copy-info</tt></dt>
<dd>Show details for copies.</dd>
</dl>
</div> <!-- new-switches -->
</div> <!-- new-features -->
<div class="h2" id="enhancements" title="enhancements">
<h2>Enhancements and Bugfixes</h2>
<div class="h3" id="listparentpath" title="listparentpath">
<h3>Listing available repositories in mod_dav_svn (<em>server</em>)</h3>
<p>The Apache HTTPD-based server can now display (in a web browser)
the collection of repositories exported by the SVNParentPath
directive: simply set '<tt>SVNListParentPath on</tt>'
in <em>httpd.conf</em>.</p>
</div> <!-- listparentpath -->
<div class="h3" id="neon25" title="neon25">
<h3>Interruptible http(s):// connections (<em>client</em>)</h3>
<p>If built with Neon 0.25.1 or higher, Subversion can be interrupted
during network operations over http:// and https://. This is a
long-standing bug that has finally been fixed.</p>
</div> <!-- neon25 -->
<div class="h3" id="_svn-hack" title="_svn-hack">
<h3>Official support for Windows '_svn' directories (<em>client and
language bindings</em>)</h3>
<p>The "<b>_svn</b>" hack is
now <a
href="http://svn.collab.net/repos/svn/trunk/notes/asp-dot-net-hack.txt">officially
supported</a>: since some versions of ASP.NET don't allow directories
beginning with dot (e.g., ".svn", the standard Subversion working copy
administrative directory), the <b>svn</b> command line client
and <b>svnversion</b> now treat the environment variable
SVN_ASP_DOT_NET_HACK specially on Windows. If this variable is set
(to any value), they will use "_svn" instead of ".svn". We recommend
that all Subversion clients running on Windows take advantage of this
behaviour. Note that once the environment variable is set, working
copies with standard ".svn" directories will stop working, and will
need to be re-checked-out to get "_svn" instead.</p>
<p class="warningmark">Third party software that uses the Subversion
libraries needs to be updated to make the equivalent API calls. See
the three new
APIs: <b>svn_wc_is_adm_dir</b>, <b>svn_wc_get_adm_dir</b>, and
<b>svn_wc_set_adm_dir</b>. Setting the SVN_ASP_DOT_NET_HACK
environment variable only works for the above-mentioned client
programs, and only on Windows. It doesn't work for libraries; users
of the libraries should call the new APIs, which are
platform-independent. See <a
href="http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=105810"
>this mail</a> and its thread for more details.</p>
</div> <!-- _svn-hack -->
<div class="h3" id="performance" title="performance">
<h3>Performance improvements (<em>client and server</em>)</h3>
<p><b>svn status</b> is a bit faster, as is any command that involves
tracing long lines of history, such as <b>svn log</b>. See <a
href="http://subversion.tigris.org/issues/show_bug.cgi?id=1970"
>issue #1970</a> for details.</p>
<p>It's particularly noticeable when <b>svn blame</b> is run on a file with a
large amount of history, or when invoking any command on an older
"peg" revision.</p>
</div> <!-- performance -->
<div class="h3" id="apis" title="apis">
<h3>API improvements (<em>client and server</em>)</h3>
<p>If you develop a 3rd-party client application that uses Subversion
APIs, you may want to take notice of some new APIs:</p>
<ul>
<li>The APIs used by 'status --show-updates' now make URI, youngest
revision, date last modified, youngest node kind, and most
recent author available as reported by the server, in addition
to the status reflected by the working copy.</li>
<li>There's now a data-transfer progress callback for ra_dav.</li>
<li>The repository root URL is now being stored as a separate field
in .svn/entries.</li>
<li>Many APIs have been revised to newer versions.</li>
</ul>
</div> <!-- apis -->
<div class="h3" id="bugfixes" title="bugfixes">
<h3>Other bugfixes (<em>client and server</em>)</h3>
<p>The usual slew of heretofore-unreleased bugfixes. See the
<a href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a>
file for full details.</p>
</div> <!-- bugfixes -->
<div class="h3" id="wc-props-change" title="wc-props-change">
<h3>Changes in the working copy format</h3>
<p>Subversion 1.3 features a minor change in the way properties are
stored in the working copy, which reduces the size of some working
copies significantly. From the user's point of view, the change is
completely transparent. That is, your working copies will go on
working, even with older clients.</p>
<p>However, programs that interact with the working copy property
files without using the official Subversion APIs or binaries may
experience problems. <a href="http://tmate.org/svn/">JavaSVN</a> is
the only project that we know of that falls into this category, and
they have been notified accordingly. If you happen to be using or
developing software that, similarly, bypasses the Subversion APIs,
then you may need to make a minor alteration to the parsing routines.
See <a
href="http://svn.collab.net/viewcvs/svn/trunk/subversion/libsvn_wc/props.c?r1=16854&r2=16855&diff_format=h">revision
16855</a> of the Subversion repository for details.</p>
</div> <!-- wc-props-change -->
</div> <!-- enhancements -->
<div class="h2" id="svn-1.1-deprecation" title="svn-1.1-deprecation">
<h2>Subversion 1.1.x series no longer supported</h2>
<p>The Subversion 1.1.x line is no longer supported. This doesn't
mean that your 1.1 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.1.x versions, and will not make any
more 1.1.x bugfix releases, except perhaps for absolutely critical
security or data-loss bugs.</p>
</div> <!-- svn-1.1-deprecation -->
</div> <!-- app -->
</body>
</html>