Google Git
Sign in
apache / subversion / refs/heads/mergeinfo-api-cleanup / . / www / svn_1.5_releasenotes.html
blob: aeac9dc9179295a9d4a7f82c0ab6761e3f895ba4 [file] [log] [blame]
<!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.5 Release Notes</title>
</head>
<body>
<div class="app">
<div class="warningmessage">
<p><strong>Note:</strong> Subversion 1.5 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>
</div>
<h1 style="text-align: center">Subversion 1.5 Release Notes</h1>
<div class="h2" id="news" title="news">
<h2>What's New in Subversion 1.5</h2>
<ul>
<li>Merge Tracking</li>
<li>Sparse checkouts</li>
<li>Copy/move-related improvements</li>
<li>Interactive conflict resolution</li>
<li>WebDAV transparent write-through proxy</li>
<li>Cyrus SASL support for ra_svn and <tt>svnserve</tt></li>
<li>Cancellation improvements</li>
<li>Changelist support</li>
<li>Relative and peg URLs in <tt>svn:externals</tt></li>
<li>FSFS sharding</li>
<li>Command-line client improvements</li>
<li>API changes, improvements and language bindings</li>
<li>Easier to try out experimental <tt>ra_serf</tt> DAV access module</li>
<li>More than XXX new bug fixes</li>
</ul>
<p>Details are described below.</p>
<p>Subversion 1.5 is a superset of all previous Subversion releases,
and is considered the current "best" release. Anything in 1.0.x
through 1.4.x is also in 1.5, but 1.5 contains features and bugfixes
not present in any earlier release. The new features will eventually
be documented in a 1.5 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="compatibility" title="compatibility">
<h2>Compatibility Concerns</h2>
<p>Older clients and servers interoperate transparently with 1.5
servers and clients. Of course, some of the new 1.5 features may not
be available unless both client and server are the latest version
(e.g. <a href="/merge-tracking/func-spec.html#migration-and-interoperability"
>Merge Tracking</a>). There is <strong>no need</strong> to dump and
reload your repositories; Subversion 1.5 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>XXX: Note new FS node-origins index (which lazily populates while
responding to queries), and new svn-populate-node-origins-index tool.</p>
<p>Subversion 1.5 maintains API/ABI compatibility with earlier
releases, by only adding new functions. A program written to the 1.0,
1.1, 1.2 or 1.3 API can both compile and run using 1.5 libraries.
However, a program written for 1.5 cannot necessarily compile or run
against older libraries. However, see the <a href="#apis">API</a>
section on some clarifications on existing APIs.</p>
<div class="h3" id="wc-and-repos-format-change" title="wc-format-change">
<h3>Working Copy and Repository Format Changes</h3>
<p>Due to certain improvements and bugfixes made to the working copy
library, the version number of the working copy format has been
incremented. This means that Subversion clients earlier than 1.5 will
<em>not</em> be able to work with working copies produced by Subversion
1.5. Similarly, the repository format has changed as well, meaning
that pre-1.5 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 originally created by Subversion
1.5.</p>
<p><strong>WARNING:</strong> if a Subversion 1.5 client encounters a pre-1.5
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, you need to be careful about which version you use in
which working copy, to avoid accidentally upgrading the working copy
format. This "auto upgrade" feature, however, does <em>not</em> occur
with the new repository format.</p>
<p>If you do accidentally upgrade a 1.4 (only) working copy, you can
use <a
href="http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py"
>this script</a> to downgrade it back 1.4. See <a
href="http://subversion.tigris.org/faq.html#working-copy-format-change"
>the FAQ</a> for details, and run the script with the
<code>--help</code> option for usage instructions.</p>
</div> <!-- wc-format-change -->
<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.5, the following changes have been
made to the output:</p>
<p>XXX: Enumerate changes to output (e.g. for changelists).</p>
<ul>
<li><p>Conflict markers in files now match the file's defined
eol-style.</p></li>
</ul>
</div> <!-- output-changes -->
</div> <!-- compatibility -->
<div class="h2" id="new-features" title="new-features">
<h2>New Features</h2>
<p>XXX: Describe each new feature. See the 1.4 RNs for a
"template".</p>
<div class="h3" id="merge-tracking" title="merge-tracking">
<h3>Merge Tracking (<em>client and server</em>)</h3>
<p>XXX</p>
</div> <!-- merge-tracking -->
<div class="h3" id="sparse-checkouts" title="sparse-checkouts">
<h3>Sparse checkouts (<em>client and server</em>)</h3>
<p>XXX: Described <a
href="http://svn.collab.net/repos/svn/trunk/notes/sparse-directories.txt"
>here</a>.</p>
</div> <!-- sparse-checkouts -->
<div class="h3" id="conflict-resolution" title="conflict-resolution">
<h3>Interactive Conflict Resolution (<em>client</em>)</h3>
<p>Added support for interactive conflict resolution in the command
line client, and a corresponding callback function in the client
library. GUI clients can use the callback function to hook in a
graphical conflict resolution program to the
<code>update</code>/<code>switch</code>/<code>merge</code>
sub-commands. Example command line output:</p>
<pre>
$ svn up
U contrib/client-side/svnmerge/svnmerge_test.py
Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
Select: (p)ostpone, (d)iff, (e)dit, (h)elp : h
(p)ostpone - mark the conflict to be resolved later
(d)iff - show all changes made to merged file
(e)dit - change merged file in an editor
(r)esolved - accept merged version of file
(m)ine - accept my version of file
(t)heirs - accept repository's version of file
(l)aunch - use third-party tool to resolve conflict
(h)elp - show this list
Select: (p)ostpone, (d)iff, (e)dit, (h)elp : t
G contrib/client-side/svnmerge/svnmerge.py
Updated to revision 25685.
</pre>
<p>This feature can be selectively disabled by using the --non-interactive
option, or disabled permanently by setting '[miscellany] interactive-conflicts
= no' in your run-time config file.</p>
<p>The API for interactive conflict resolution is exposed via a
callback function and the following new data types:</p>
<ul>
<li><code>svn_wc_conflict_resolver_func_t</code>, the callback API
itself</li>
<li><code>svn_wc_conflict_description_t</code>, a description of the
conflict passed to the callback</li>
<li><code>svn_wc_conflict_action_t</code>, the part of the conflict
description indicating what the merge was trying to do</li>
<li><code>svn_wc_conflict_reason_t</code>, the part of the conflict
description indicating the type of conflict</li>
<li><code>svn_wc_conflict_result_t</code>, returned by the callback
as the result of any conflict resolution attempt</li>
</ul>
<p>Clients provide their callback function to Subversion's libraries
by setting it on the (new) <code>conflict_func</code> field of their
<code>svn_client_ctx_t</code>, and may provide additional state to the
callback via the corresponding <code>conflict_baton</code> field.</p>
</div> <!-- conflict-resolution -->
<div class="h3" id="webdav-proxy" title="webdav-proxy">
<h3>WebDAV transparent write-through proxy (<em>server</em>)</h3>
<p>XXX: A <a href="http://svn.collab.net/repos/svn/trunk/notes/webdav-proxy"
>mod_dav_svn feature</a> activated using the SVNMasterURI directive in
httpd.conf.</p>
</div> <!-- webdav-proxy -->
<div class="h3" id="cyrus-sasl" title="cyrus-sasl">
<h3>Cyrus SASL support for ra_svn and <tt>svnserve</tt> (<em>client
and server</em>)</h3>
<p>XXX: Described <a
href="http://svn.collab.net/repos/svn/trunk/notes/sasl.txt">here</a>.</p>
</div> <!-- cyrus-sasl -->
<div class="h3" id="changelist-support" title="changelist-support">
<h3>Changelist support (<em>client</em>)</h3>
<p>XXX: Described <a
href="http://svn.collab.net/repos/svn/trunk/notes/changelist-design.txt"
>here</a>.</p>
</div> <!-- changelist-support -->
<div class="h3" id="relative-externals" title="relative-externals">
<h3>Relative peg URLs in <tt>svn:externals</tt></h3>
<p>Two additions to the <tt>svn:externals</tt> feature</p>
<ul>
<li>
<p>
The URLs may include peg specifications. Because the
directory a URL refers to with and without a peg revision uses
a different lookup and result in different contents, the
current format from older versions of Subversion continues to
not understand peg revisions. A new format is introduced to
allow peg revisions in URLs.
</p>
<p>So the old format of</p>
<pre>
foo http://example.com/repos/zig
foo/bar -r 1234 http://example.com/repos/zag
</pre>
<p>does not support peg revisions. In fact, these following
externals will not work unless there are directories named
<tt>zig@HEAD</tt> and <tt>zag@HEAD</tt>:</p>
<pre>
foo http://example.com/repos/zig@HEAD
foo/bar -r 1234 http://example.com/repos/zag@HEAD
</pre>
<p>
The new format moves the URL first followed by the directory
the external is checked out or exported into</p>
<pre>
http://example.com/repos/zig foo1
-r 1234 http://example.com/repos/zag foo/bar1
http://example.com/repos/zig@HEAD foo2
-r 1234 http://example.com/repos/zag@HEAD foo/bar2
</pre>
<p>peg specifications are allowed but not necessary.
</p>
</li>
<li>
<p>
Up to Subversion 1.4, the URLs in an <tt>svn:externals</tt>
specification must be absolute. Now they can be relative.
Four different relative externals are supported.
</p>
<p>
For the following example, assume we have two repositories at
<tt>http://example.com/svn/repos-1</tt> and
<tt>http://example.com/svn/repos-2</tt>. We have a checkout
of <tt>http://example.com/svn/repos-1/project1/trunk</tt> and
the <tt>svn:external</tt> property is set on <tt>trunk</tt>.</p>
<ul>
<li>
<tt>../</tt>
<br/>
Relative to the directory with the <tt>svn:external</tt>
property. These URLs always begin with the string
<tt>../</tt>.
<pre>
../../project2/trunk common/project2/trunk
</pre>
This will extract
<tt>http://example.com/svn/repos-1/project2/trunk</tt>
into <tt>common/project2/trunk</tt>. The URL is relative
to the directory with the <tt>svn:external</tt>, not the
directory where the external is written to disk.
</li>
<li>
<tt>^/</tt>
<br/>
Relative to the repository root.
<pre>
^/project2/trunk common/project2/trunk
</pre>
This will extract
<tt>http://example.com/svn/repos-1/project2/trunk</tt>
into <tt>common/project2/trunk</tt>.
<br/>
You can also refer to other repositories easily using
repository root relative URLs:
<pre>
^/../repos-2/foo/trunk common/foo/trunk
</pre>
This will extract
<tt>http://example.com/svn/repos-2/foo/trunk</tt> into
<tt>common/foo/trunk</tt>
</li>
<li>
<tt>//</tt>
<br/>
Relative to the scheme. This copies the scheme of the
checkout or export URL into the URL in the
<tt>svn:external</tt>. It is useful when the same
hostname must the accessed with different scheme's
depending upon network location; i.e. clients in the
intranet use <tt>http://</tt> while external clients use
<tt>svn+ssh://</tt>.
<pre>
//example.com/svn/repos-1/project2/trunk common/project2/trunk
</pre>
This will extract
<tt>http://example.com/svn/repos-1/project2/trunk</tt>
into <tt>common/project2/trunk</tt>. If the working copy
was checked out from
<tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt>
then this URL would be
<tt>http://example.com/svn/repos-1/project1/trunk</tt>.
</li>
<li>
<tt>/</tt>
<br/>
Server root relative URLs. This copies the scheme and
hostname from the checkout or export URL into the
<tt>svn:external</tt> URL.
<pre>
/svn/repos-1/project2/trunk common/project2/trunk
</pre>
This will extract
<tt>http://example.com/svn/repos-1/project2/trunk</tt>
into <tt>common/project2/trunk</tt>. If the working copy
was checked out from
<tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt>
then this URL would be
<tt>http://example.com/svn/repos-1/project1/trunk</tt>.
</li>
</ul>
<p>
Relative URLs are supported in the old <tt>svn:externals</tt>
format that do not support peg revisions.
</p>
<p>
When Subversion sees an <tt>svn:externals</tt> without an
absolute URL it takes the first argument as a relative URL and
the second as the target directory.
</p>
</li>
</ul>
</div> <!-- relative-externals -->
<div class="h3" id="fsfs-sharding" title="fsfs-sharding">
<h3>FSFS sharding</h3>
<p>XXX: Useful for file systems which don't perform well with a large
number of files in a directory -- see blog entry <a
href="http://www.farside.org.uk/200704/tree_structured_fsfs">here</a>.
<!-- ### Reshard script is not quite finished and currently
### aborts if you try to run it.
<a
href="http://svn.collab.net/repos/svn/trunk/tools/server-side/fsfs-reshard.py"
>Migration script</a> provided.
-->
</p>
</div> <!-- fsfs-sharding -->
</div> <!-- new-features -->
<div class="h2" id="enhancements" title="enhancements">
<h2>Enhancements and Bugfixes</h2>
<div class="h3" id="copy-move-improvements" title="copy-move-improvements">
<h3>Copy/move-related improvements (<em>client and server</em>)</h3>
<p>The abilities and behavior of <code>copy</code> and
<code>move</code> operations has improved significantly.</p>
<div class="h4" id="leverage-copyfrom" title="leverage-copyfrom">
<h4>Improved copy-handling during updates (<em>client and server</em>)</h4>
<p>A common problem in older versions of Subversion was the way in
which <code>svn update</code> handled incoming copies and moves.</p>
<p>For example, suppose Harry runs <code>svn move foo bar; svn
commit</code>, and meanwhile Sally makes local changes to 'foo', and
then runs <code>svn update</code>. In earlier versions of Subversion,
the server would send down a completely new file 'bar', and remove the
file 'foo' (or rather, make it unversioned, since it has uncommitted
changes.) From Sally's point of view, her changes seem to be lost;
the newly added 'bar' file has the older content. In Subversion 1.5,
the client and server both attempt to be smarter about this. The
server doesn't send a whole new file during the update, but rather
instructions to copy something that may likely already exists in the
working copy. So Sally's 'foo' file is copied to 'bar' (with local
edits intact!).</p>
<p>In theory, this is the best-case scenario. There are a few
caveats: this "proper copying" of existing working-copy resources only
works on files, not (yet) on directories. Also, if an incoming
move-operation deletes 'foo' before it attempts to copy it to 'bar',
then the copy will fail, and the client reverts to the old behavior of
fetching a pristine copy of the file from the repository. We hope to
address this in svn 1.6. For details on the this issue see <a
href="http://subversion.tigris.org/issues/show_bug.cgi?id=503">issue
#503</a>.</p>
</div> <!-- leverage-copyfrom -->
<div class="h4" id="copy-peg-revs" title="copy-peg-revs">
<h4>Peg revisions (<em>client</em>)</h4>
<p>Copy operations now accept sources with peg revisions.</p>
</div> <!-- copy-peg-revs -->
<div class="h4" id="multi-op-copy-move" title="multi-op-copy-move">
<h4>Multiple working copy copy/move operations (<em>client</em>)</h4>
<p>Clients may now perform multiple local copy/move operations on a
single object in a working copy:</p>
<blockquote><pre><code>
svn mv path1 path2
svn mv path2 path3
</code></pre></blockquote>
</div> <!-- multi-op-copy-move -->
<div class="h4" id="multi-src-copy" title="multi-src-copy">
<h4>Improved handling multiple copy/move sources (<em>client</em>)</h4>
<p>Clients now accept multiple sources for copy and move operations, with
the ability to copy/move each of the sources to the specified directory.
This mirrors the behavior of standard command-line copy and move tools,
such as <code>cp</code> and <code>mv</code>. In practice, this means
users can take advantage of shell globbing when doing a local copy
or move:</p>
<blockquote><pre><code>
svn cp *.c dir
</code></pre></blockquote>
<p>Multiple source copy/move also works for all previously defined
copy/move working copy and repository combinations. This was
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=747">issue
#747</a>.</p>
</div> <!-- multi-src-copy -->
</div> <!-- copy-move-improvements -->
<div class="h3" id="cancellation-improvements"
title="cancellation-improvements">
<h3>Cancellation improvements (<em>client</em>)</h3>
<p>Clients operations are now significantly more responsive to
cancellation (e.g. via <tt>control-c</tt>). In pre-1.5 releases,
after directing an operation to stop, one sometimes had to wait for
some time (e.g. while I/O occurred) before the operation would
actually stop.</p>
</div> <!-- cancellation-improvements -->
<div class="h3" id="cmdline" title="cmdline">
<h3>Command-line client improvements (<em>client</em>)</h3>
<ul>
<li>A <code>--use-merge-history</code> option to adhere to Merge
Tracking meta data has been added to the following sub-commands:
<ul>
<!-- li>blame</li -->
<li>log</li>
<li>merge</li>
</ul>
</li>
<li>A <code>--parents</code> option to create intermediate
directories has been added to the following sub-commands:
<ul>
<li>add</li>
<li>copy</li>
<li>move</li>
<li>mkdir</li>
</ul>
</li>
<!-- ### Anticipated addition(s):
### double-dash sequences inside comment changed to '++' to
### avoid breaking XML rules.
<li><code>++merged-from</code> and <code>++merged-to</code> options
to report on merge info have been added to the <code>info</code>
sub-command.</li>
<li>An <code>++accept=orig|mine|repo</code> option to select which
version of a path to retain has been added to the
<code>resolved</code> sub-command.</li>
-->
<li>A <code>--keep-local</code> option to retain paths locally has
been added to the <code>delete</code> sub-command.</li>
</ul>
<p>XXX: More...</p>
</div> <!-- cmdline -->
<div class="h3" id="apis" title="apis">
<h3>API changes, improvements and language bindings
(<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 the following changes and new
APIs:</p>
<ul>
<li><tt>svn_opt_parse_path()</tt> changes
<ul>
<li>
Since Subversion 1.3, if a path or URL ends in an empty
revision suffix '@', then the returned revision type would be
different than an unprotected path or URL:
<ul>
<li>
<tt>some/path/to/foo</tt> returns
<tt>svn_opt_revision_unspecified</tt>
</li>
<li>
<tt>some/path/to/foo<b>@</b></tt> returns
<tt>svn_opt_revision_base</tt>
</li>
<li>
<tt>http://example.com/some/path/to/foo</tt> returns
<tt>svn_opt_revision_unspecified</tt>
</li>
<li>
<tt>http://example.com/some/path/to/foo@</tt> returns
<tt>svn_opt_revision_head</tt>
</li>
</ul>
Subversion 1.5 fixes this inconsistency, all the above paths
and URLs return <tt>svn_opt_revision_unspecified</tt>.
</li>
<li>
Since Subversion 1.2, <tt>svn_opt_parse_path</tt> would always
canonicalize the returned path or URL with
<tt>svn_path_canonicalize</tt>, even though this is not
documented in <tt>subversion/include/svn_opt.h</tt>. For the
relative externals support, uncanonicalized paths need to be
returned, otherwise scheme relative URLs,
i.e. <tt>//example.com/some/path</tt> would be canonicalized
to server root relative URLs <tt>/example.com/some/path</tt>.
Users of this function now must ensure that they canonicalize
the result of this function if they pass it to any other
Subversion functions that expect a canonicalized path or URL.
</li>
</ul>
</li>
<li>XXX: Enumerate specific new API additions (e.g. merge info
retrieval?)</li>
<li>APIs backing the new <a href="#cmdline">Command-line client
improvements</a> section have been added.</li>
<li>Many APIs have been revised to newer versions.</li>
<li>Language bindings expanded and improved</li>
</ul>
</div> <!-- apis -->
<div class="h3" id="dav-modules" title="dav-modules">
<h3>Easier to try out experimental <tt>ra_serf</tt> DAV access module
(<em>client</em>)</h3>
<p>Subversion 1.4 introduced the experimental <tt>ra_serf</tt>
repository access module for accessing HTTP[S] DAV Subversion servers.
This uses the <a href="http://code.google.com/p/serf/">serf</a>
library instead of the Neon library which the original DAV support
uses. serf supports pipelined requests which may lead to better
performance. However, Subversion 1.4 required you to choose which
module to use for accessing DAV servers at build time, which made it
difficult to find out which module performs better for your usage
patterns.</p>
<p>Subversion 1.5 allows you to build both modules at the same time;
you can choose which library to use on a global or host-by-host basis
by setting the <tt>http-library</tt> variable in your run-time server
configuration file (<tt>~/.subversion/servers</tt>). In recognition
of the fact that both libraries are DAV clients, we have
renamed <tt>ra_dav</tt> to <tt>ra_neon</tt>.</p>
</div> <!-- dav-modules -->
<div class="h3" id="bug-fixes" title="bug-fixes">
<h3>Other bug fixes (<em>client and server</em>)</h3>
<p>The usual slew of heretofore-unreleased bug fixes, more than 40
overall. See the
<a href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a>
file for full details.</p>
</div> <!-- bug-fixes -->
</div> <!-- enhancements -->
<div class="h2" id="svn-1.3-deprecation" title="svn-1.3-deprecation">
<h2>Subversion 1.3.x series no longer supported</h2>
<p>The Subversion 1.3.x line is no longer supported. This doesn't
mean that your 1.3 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.3.x versions, and will not make any
more 1.3.x bugfix releases, except perhaps for absolutely critical
security or data-loss bugs.</p>
</div> <!-- svn-1.3-deprecation -->
</div> <!-- app -->
</body>
</html>