www/svn_1.5_releasenotes.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4 <head>
   5 <style type="text/css"> /* <![CDATA[ */
   6   @import "branding/css/tigris.css";
   7   @import "branding/css/inst.css";
   8   /* ]]> */</style>
   9 <link rel="stylesheet" type="text/css" media="print"
  10   href="branding/css/print.css"/>
  11 <script type="text/javascript" src="branding/scripts/tigris.js"></script>
  12 <title>Subversion 1.5 Release Notes</title>
  13 </head>
  14
  15 <body>
  16 <div class="app">
  17
  18 <div class="warningmessage">
  19 <p><strong>Note:</strong> Subversion 1.5 is <em>not released yet</em>.
  20 When it is released, this warning message will disappear, and the rest
  21 of this page will become the release notes.  Until then, this page
  22 describes what is planned for the release.</p>
  23 </div>
  24
  25 <h1 style="text-align: center">Subversion 1.5 Release Notes</h1>
  26
  27 <div class="h2" id="news" title="news">
  28 <h2>What's New in Subversion 1.5</h2>
  29
  30 <ul>
  31   <li>Merge Tracking</li>
  32   <li>Sparse checkouts</li>
  33   <li>Copy/move-related improvements</li>
  34   <li>Interactive conflict resolution</li>
  35   <li>WebDAV transparent write-through proxy</li>
  36   <li>Cyrus SASL support for ra_svn and <tt>svnserve</tt></li>
  37   <li>Cancellation improvements</li>
  38   <li>Changelist support</li>
  39   <li>Relative and peg URLs in <tt>svn:externals</tt></li>
  40   <li>FSFS sharding</li>
  41   <li>Command-line client improvements</li>
  42   <li>API changes, improvements and language bindings</li>
  43   <li>Easier to try out experimental <tt>ra_serf</tt> DAV access module</li>
  44   <li>More than XXX new bug fixes</li>
  45 </ul>
  46
  47 <p>Details are described below.</p>
  48
  49 <p>Subversion 1.5 is a superset of all previous Subversion releases,
  50 and is considered the current "best" release.  Anything in 1.0.x
  51 through 1.4.x is also in 1.5, but 1.5 contains features and bugfixes
  52 not present in any earlier release.  The new features will eventually
  53 be documented in a 1.5 version of the free Subversion book, see <a
  54 href="http://svnbook.red-bean.com">svnbook.red-bean.com</a>.</p>
  55
  56 </div>  <!-- news -->
  57
  58 <div class="h2" id="compatibility" title="compatibility">
  59 <h2>Compatibility Concerns</h2>
  60
  61 <p>Older clients and servers interoperate transparently with 1.5
  62 servers and clients.  Of course, some of the new 1.5 features may not
  63 be available unless both client and server are the latest version
  64 (e.g. <a href="/merge-tracking/func-spec.html#migration-and-interoperability"
  65 >Merge Tracking</a>).  There is <strong>no need</strong> to dump and
  66 reload your repositories; Subversion 1.5 can read repositories created
  67 by earlier versions.  To upgrade an existing installation, just
  68 install the newest libraries and binaries on top of the older
  69 ones.</p>
  70
  71 <p>XXX: Note new FS node-origins index (which lazily populates while
  72 responding to queries), and new svn-populate-node-origins-index tool.</p>
  73
  74 <p>Subversion 1.5 maintains API/ABI compatibility with earlier
  75 releases, by only adding new functions.  A program written to the 1.0,
  76 1.1, 1.2 or 1.3 API can both compile and run using 1.5 libraries.
  77 However, a program written for 1.5 cannot necessarily compile or run
  78 against older libraries.  However, see the <a href="#apis">API</a>
  79 section on some clarifications on existing APIs.</p>
  80
  81 <div class="h3" id="wc-and-repos-format-change" title="wc-format-change">
  82 <h3>Working Copy and Repository Format Changes</h3>
  83
  84 <p>Due to certain improvements and bugfixes made to the working copy
  85 library, the version number of the working copy format has been
  86 incremented. This means that Subversion clients earlier than 1.5 will
  87 <em>not</em> be able to work with working copies produced by Subversion
  88 1.5.  Similarly, the repository format has changed as well, meaning
  89 that pre-1.5 Subversion tools that normally access a repository
  90 directly (e.g. <tt>svnserve</tt>, <tt>mod_dav_svn</tt>, <tt>svnadmin</tt>)
  91 won't be able to read a repository originally created by Subversion
  92 1.5.</p>
  93
  94 <p><strong>WARNING:</strong> if a Subversion 1.5 client encounters a pre-1.5
  95 working copy, it will <em>automatically</em> upgrade the working copy
  96 format as soon as it touches it, making it unreadable by older
  97 Subversion clients.  If you are using several versions of Subversion
  98 on your machine, you need to be careful about which version you use in
  99 which working copy, to avoid accidentally upgrading the working copy
 100 format.  This "auto upgrade" feature, however, does <em>not</em> occur
 101 with the new repository format.</p>
 102
 103 <p>If you do accidentally upgrade a 1.4 (only) working copy, you can
 104 use <a
 105 href="http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py"
 106 >this script</a> to downgrade it back 1.4.  See <a
 107 href="http://subversion.tigris.org/faq.html#working-copy-format-change"
 108 >the FAQ</a> for details, and run the script with the
 109 <code>--help</code> option for usage instructions.</p>
 110
 111 </div>  <!-- wc-format-change -->
 112
 113 <div class="h3" id="output-changes" title="output-changes">
 114 <h3>Command Line Output Changes</h3>
 115
 116 <p>Although the Subversion developers try hard to keep output from the
 117 command line programs compatible between releases, new information
 118 sometimes has to be added.  This might break scripts that rely on the
 119 exact format of the output.  In 1.5, the following changes have been
 120 made to the output:</p>
 121
 122 <p>XXX: Enumerate changes to output (e.g. for changelists).</p>
 123
 124 <ul>
 125   <li><p>Conflict markers in files now match the file's defined
 126     eol-style.</p></li>
 127 </ul>
 128
 129 </div>  <!-- output-changes -->
 130
 131 </div>  <!-- compatibility -->
 132
 133 <div class="h2" id="new-features" title="new-features">
 134 <h2>New Features</h2>
 135
 136 <p>XXX: Describe each new feature.  See the 1.4 RNs for a
 137 "template".</p>
 138
 139 <div class="h3" id="merge-tracking" title="merge-tracking">
 140 <h3>Merge Tracking (<em>client and server</em>)</h3>
 141
 142 <p>XXX</p>
 143
 144 </div> <!-- merge-tracking -->
 145
 146 <div class="h3" id="sparse-checkouts" title="sparse-checkouts">
 147 <h3>Sparse checkouts (<em>client and server</em>)</h3>
 148
 149 <p>XXX: Described <a
 150 href="http://svn.collab.net/repos/svn/trunk/notes/sparse-directories.txt"
 151 >here</a>.</p>
 152
 153 </div> <!-- sparse-checkouts -->
 154
 155 <div class="h3" id="conflict-resolution" title="conflict-resolution">
 156 <h3>Interactive Conflict Resolution (<em>client</em>)</h3>
 157
 158 <p>Added support for interactive conflict resolution in the command
 159 line client, and a corresponding callback function in the client
 160 library.  GUI clients can use the callback function to hook in a
 161 graphical conflict resolution program to the
 162 <code>update</code>/<code>switch</code>/<code>merge</code>
 163 sub-commands.  Example command line output:</p>
 164 <pre>
 165     $ svn up
 166     U    contrib/client-side/svnmerge/svnmerge_test.py
 167     Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
 168     Select: (p)ostpone, (d)iff, (e)dit, (h)elp : h
 169       (p)ostpone - mark the conflict to be resolved later
 170       (d)iff     - show all changes made to merged file
 171       (e)dit     - change merged file in an editor
 172       (r)esolved - accept merged version of file
 173       (m)ine     - accept my version of file
 174       (t)heirs   - accept repository's version of file
 175       (l)aunch   - use third-party tool to resolve conflict
 176       (h)elp     - show this list
 177
 178     Select: (p)ostpone, (d)iff, (e)dit, (h)elp : t
 179     G    contrib/client-side/svnmerge/svnmerge.py
 180     Updated to revision 25685.
 181 </pre>
 182 <p>This feature can be selectively disabled by using the --non-interactive
 183 option, or disabled permanently by setting '[miscellany] interactive-conflicts
 184  = no' in your run-time config file.</p>
 185
 186 <p>The API for interactive conflict resolution is exposed via a
 187 callback function and the following new data types:</p>
 188
 189 <ul>
 190   <li><code>svn_wc_conflict_resolver_func_t</code>, the callback API
 191     itself</li>
 192   <li><code>svn_wc_conflict_description_t</code>, a description of the
 193     conflict passed to the callback</li>
 194   <li><code>svn_wc_conflict_action_t</code>, the part of the conflict
 195     description indicating what the merge was trying to do</li>
 196   <li><code>svn_wc_conflict_reason_t</code>, the part of the conflict
 197     description indicating the type of conflict</li>
 198   <li><code>svn_wc_conflict_result_t</code>, returned by the callback
 199     as the result of any conflict resolution attempt</li>
 200 </ul>
 201
 202 <p>Clients provide their callback function to Subversion's libraries
 203 by setting it on the (new) <code>conflict_func</code> field of their
 204 <code>svn_client_ctx_t</code>, and may provide additional state to the
 205 callback via the corresponding <code>conflict_baton</code> field.</p>
 206
 207 </div>  <!-- conflict-resolution -->
 208
 209 <div class="h3" id="webdav-proxy" title="webdav-proxy">
 210 <h3>WebDAV transparent write-through proxy (<em>server</em>)</h3>
 211
 212 <p>XXX: A <a href="http://svn.collab.net/repos/svn/trunk/notes/webdav-proxy"
 213 >mod_dav_svn feature</a> activated using the SVNMasterURI directive in
 214 httpd.conf.</p>
 215
 216 </div>  <!-- webdav-proxy -->
 217
 218 <div class="h3" id="cyrus-sasl" title="cyrus-sasl">
 219 <h3>Cyrus SASL support for ra_svn and <tt>svnserve</tt> (<em>client
 220 and server</em>)</h3>
 221
 222 <p>XXX: Described <a
 223 href="http://svn.collab.net/repos/svn/trunk/notes/sasl.txt">here</a>.</p>
 224
 225 </div> <!-- cyrus-sasl -->
 226
 227 <div class="h3" id="changelist-support" title="changelist-support">
 228 <h3>Changelist support (<em>client</em>)</h3>
 229
 230 <p>XXX: Described <a
 231 href="http://svn.collab.net/repos/svn/trunk/notes/changelist-design.txt"
 232 >here</a>.</p>
 233
 234 </div>  <!-- changelist-support -->
 235
 236 <div class="h3" id="relative-externals" title="relative-externals">
 237 <h3>Relative peg URLs in <tt>svn:externals</tt></h3>
 238
 239 <p>Two additions to the <tt>svn:externals</tt> feature</p>
 240   <ul>
 241     <li>
 242       <p>
 243         The URLs may include peg specifications.  Because the
 244         directory a URL refers to with and without a peg revision uses
 245         a different lookup and result in different contents, the
 246         current format from older versions of Subversion continues to
 247         not understand peg revisions.  A new format is introduced to
 248         allow peg revisions in URLs.
 249       </p>
 250       <p>So the old format of</p>
 251         <pre>
 252           foo             http://example.com/repos/zig
 253           foo/bar -r 1234 http://example.com/repos/zag
 254         </pre>
 255         <p>does not support peg revisions.  In fact, these following
 256         externals will not work unless there are directories named
 257         <tt>zig@HEAD</tt> and <tt>zag@HEAD</tt>:</p>
 258         <pre>
 259           foo             http://example.com/repos/zig@HEAD
 260           foo/bar -r 1234 http://example.com/repos/zag@HEAD
 261         </pre>
 262       <p>
 263         The new format moves the URL first followed by the directory
 264         the external is checked out or exported into</p>
 265         <pre>
 266           http://example.com/repos/zig foo1
 267           -r 1234 http://example.com/repos/zag foo/bar1
 268           http://example.com/repos/zig@HEAD foo2
 269           -r 1234 http://example.com/repos/zag@HEAD foo/bar2
 270         </pre>
 271         <p>peg specifications are allowed but not necessary.
 272       </p>
 273     </li>
 274     <li>
 275       <p>
 276         Up to Subversion 1.4, the URLs in an <tt>svn:externals</tt>
 277         specification must be absolute.  Now they can be relative.
 278         Four different relative externals are supported.
 279       </p>
 280       <p>
 281         For the following example, assume we have two repositories at
 282         <tt>http://example.com/svn/repos-1</tt> and
 283         <tt>http://example.com/svn/repos-2</tt>.  We have a checkout
 284         of <tt>http://example.com/svn/repos-1/project1/trunk</tt> and
 285         the <tt>svn:external</tt> property is set on <tt>trunk</tt>.</p>
 286         <ul>
 287           <li>
 288             <tt>../</tt>
 289             <br/>
 290             Relative to the directory with the <tt>svn:external</tt>
 291             property.  These URLs always begin with the string
 292             <tt>../</tt>.
 293             <pre>
 294               ../../project2/trunk common/project2/trunk
 295             </pre>
 296             This will extract
 297             <tt>http://example.com/svn/repos-1/project2/trunk</tt>
 298             into <tt>common/project2/trunk</tt>.  The URL is relative
 299             to the directory with the <tt>svn:external</tt>, not the
 300             directory where the external is written to disk.
 301           </li>
 302           <li>
 303             <tt>^/</tt>
 304             <br/>
 305             Relative to the repository root.
 306             <pre>
 307               ^/project2/trunk common/project2/trunk
 308             </pre>
 309             This will extract
 310             <tt>http://example.com/svn/repos-1/project2/trunk</tt>
 311             into <tt>common/project2/trunk</tt>.
 312             <br/>
 313
 314             You can also refer to other repositories easily using
 315             repository root relative URLs:
 316             <pre>
 317               ^/../repos-2/foo/trunk common/foo/trunk
 318             </pre>
 319             This will extract
 320             <tt>http://example.com/svn/repos-2/foo/trunk</tt> into
 321             <tt>common/foo/trunk</tt>
 322           </li>
 323           <li>
 324             <tt>//</tt>
 325             <br/>
 326             Relative to the scheme.  This copies the scheme of the
 327             checkout or export URL into the URL in the
 328             <tt>svn:external</tt>.  It is useful when the same
 329             hostname must the accessed with different scheme's
 330             depending upon network location; i.e. clients in the
 331             intranet use <tt>http://</tt> while external clients use
 332             <tt>svn+ssh://</tt>.
 333             <pre>
 334               //example.com/svn/repos-1/project2/trunk common/project2/trunk
 335             </pre>
 336             This will extract
 337             <tt>http://example.com/svn/repos-1/project2/trunk</tt>
 338             into <tt>common/project2/trunk</tt>.  If the working copy
 339             was checked out from
 340             <tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt>
 341             then this URL would be
 342             <tt>http://example.com/svn/repos-1/project1/trunk</tt>.
 343           </li>
 344           <li>
 345             <tt>/</tt>
 346             <br/>
 347
 348             Server root relative URLs.  This copies the scheme and
 349             hostname from the checkout or export URL into the
 350             <tt>svn:external</tt> URL.
 351             <pre>
 352               /svn/repos-1/project2/trunk common/project2/trunk
 353             </pre>
 354             This will extract
 355             <tt>http://example.com/svn/repos-1/project2/trunk</tt>
 356             into <tt>common/project2/trunk</tt>.  If the working copy
 357             was checked out from
 358             <tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt>
 359             then this URL would be
 360             <tt>http://example.com/svn/repos-1/project1/trunk</tt>.
 361           </li>
 362         </ul>
 363       <p>
 364         Relative URLs are supported in the old <tt>svn:externals</tt>
 365         format that do not support peg revisions.
 366       </p>
 367       <p>
 368         When Subversion sees an <tt>svn:externals</tt> without an
 369         absolute URL it takes the first argument as a relative URL and
 370         the second as the target directory.
 371       </p>
 372     </li>
 373   </ul>
 374
 375 </div>  <!-- relative-externals -->
 376
 377 <div class="h3" id="fsfs-sharding" title="fsfs-sharding">
 378 <h3>FSFS sharding</h3>
 379
 380 <p>XXX: Useful for file systems which don't perform well with a large
 381 number of files in a directory -- see blog entry <a
 382 href="http://www.farside.org.uk/200704/tree_structured_fsfs">here</a>.
 383 <!-- ### Reshard script is not quite finished and currently
 384      ### aborts if you try to run it.
 385  <a
 386  href="http://svn.collab.net/repos/svn/trunk/tools/server-side/fsfs-reshard.py"
 387  >Migration script</a> provided.
 388 -->
 389 </p>
 390
 391 </div>  <!-- fsfs-sharding -->
 392
 393 </div>  <!-- new-features -->
 394
 395
 396 <div class="h2" id="enhancements" title="enhancements">
 397 <h2>Enhancements and Bugfixes</h2>
 398
 399 <div class="h3" id="copy-move-improvements" title="copy-move-improvements">
 400 <h3>Copy/move-related improvements (<em>client and server</em>)</h3>
 401
 402 <p>The abilities and behavior of <code>copy</code> and
 403 <code>move</code> operations has improved significantly.</p>
 404
 405
 406 <div class="h4" id="leverage-copyfrom" title="leverage-copyfrom">
 407 <h4>Improved copy-handling during updates (<em>client and server</em>)</h4>
 408
 409 <p>A common problem in older versions of Subversion was the way in
 410 which <code>svn update</code> handled incoming copies and moves.</p>
 411
 412 <p>For example, suppose Harry runs <code>svn move foo bar; svn
 413 commit</code>, and meanwhile Sally makes local changes to 'foo', and
 414 then runs <code>svn update</code>.  In earlier versions of Subversion,
 415 the server would send down a completely new file 'bar', and remove the
 416 file 'foo' (or rather, make it unversioned, since it has uncommitted
 417 changes.)  From Sally's point of view, her changes seem to be lost;
 418 the newly added 'bar' file has the older content.  In Subversion 1.5,
 419 the client and server both attempt to be smarter about this.  The
 420 server doesn't send a whole new file during the update, but rather
 421 instructions to copy something that may likely already exists in the
 422 working copy.  So Sally's 'foo' file is copied to 'bar' (with local
 423 edits intact!).</p>
 424
 425 <p>In theory, this is the best-case scenario.  There are a few
 426 caveats: this "proper copying" of existing working-copy resources only
 427 works on files, not (yet) on directories.  Also, if an incoming
 428 move-operation deletes 'foo' before it attempts to copy it to 'bar',
 429 then the copy will fail, and the client reverts to the old behavior of
 430 fetching a pristine copy of the file from the repository.  We hope to
 431 address this in svn 1.6.  For details on the this issue see <a
 432 href="http://subversion.tigris.org/issues/show_bug.cgi?id=503">issue
 433 #503</a>.</p>
 434
 435 </div> <!-- leverage-copyfrom -->
 436
 437 <div class="h4" id="copy-peg-revs" title="copy-peg-revs">
 438 <h4>Peg revisions (<em>client</em>)</h4>
 439
 440 <p>Copy operations now accept sources with peg revisions.</p>
 441
 442 </div>  <!-- copy-peg-revs -->
 443
 444 <div class="h4" id="multi-op-copy-move" title="multi-op-copy-move">
 445 <h4>Multiple working copy copy/move operations (<em>client</em>)</h4>
 446
 447 <p>Clients may now perform multiple local copy/move operations on a
 448 single object in a working copy:</p>
 449 <blockquote><pre><code>
 450 svn mv path1 path2
 451 svn mv path2 path3
 452 </code></pre></blockquote>
 453
 454 </div>  <!-- multi-op-copy-move -->
 455
 456 <div class="h4" id="multi-src-copy" title="multi-src-copy">
 457 <h4>Improved handling multiple copy/move sources (<em>client</em>)</h4>
 458
 459 <p>Clients now accept multiple sources for copy and move operations, with
 460 the ability to copy/move each of the sources to the specified directory.
 461 This mirrors the behavior of standard command-line copy and move tools,
 462 such as <code>cp</code> and <code>mv</code>.  In practice, this means
 463 users can take advantage of shell globbing when doing a local copy
 464 or move:</p>
 465 <blockquote><pre><code>
 466 svn cp *.c dir
 467 </code></pre></blockquote>
 468
 469 <p>Multiple source copy/move also works for all previously defined
 470 copy/move working copy and repository combinations.  This was
 471 <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=747">issue
 472 #747</a>.</p>
 473
 474 </div>  <!-- multi-src-copy -->
 475
 476 </div>  <!-- copy-move-improvements -->
 477
 478 <div class="h3" id="cancellation-improvements"
 479      title="cancellation-improvements">
 480 <h3>Cancellation improvements (<em>client</em>)</h3>
 481
 482 <p>Clients operations are now significantly more responsive to
 483 cancellation (e.g. via <tt>control-c</tt>).  In pre-1.5 releases,
 484 after directing an operation to stop, one sometimes had to wait for
 485 some time (e.g. while I/O occurred) before the operation would
 486 actually stop.</p>
 487
 488 </div>  <!-- cancellation-improvements -->
 489
 490 <div class="h3" id="cmdline" title="cmdline">
 491 <h3>Command-line client improvements (<em>client</em>)</h3>
 492
 493 <ul>
 494   <li>A <code>--use-merge-history</code> option to adhere to Merge
 495     Tracking meta data has been added to the following sub-commands:
 496     <ul>
 497       <!-- li>blame</li -->
 498       <li>log</li>
 499       <li>merge</li>
 500     </ul>
 501   </li>
 502
 503   <li>A <code>--parents</code> option to create intermediate
 504     directories has been added to the following sub-commands:
 505     <ul>
 506       <li>add</li>
 507       <li>copy</li>
 508       <li>move</li>
 509       <li>mkdir</li>
 510     </ul>
 511   </li>
 512
 513   <!-- ### Anticipated addition(s):
 514        ### double-dash sequences inside comment changed to '++' to
 515        ### avoid breaking XML rules.
 516   <li><code>++merged-from</code> and <code>++merged-to</code> options
 517     to report on merge info have been added to the <code>info</code>
 518     sub-command.</li>
 519
 520   <li>An <code>++accept=orig|mine|repo</code> option to select which
 521     version of a path to retain has been added to the
 522     <code>resolved</code> sub-command.</li>
 523   -->
 524
 525   <li>A <code>--keep-local</code> option to retain paths locally has
 526     been added to the <code>delete</code> sub-command.</li>
 527 </ul>
 528
 529 <p>XXX: More...</p>
 530
 531 </div>  <!-- cmdline -->
 532
 533 <div class="h3" id="apis" title="apis">
 534 <h3>API changes, improvements and language bindings
 535     (<em>client and server</em>)</h3>
 536
 537 <p>If you develop a 3rd-party client application that uses Subversion
 538   APIs, you may want to take notice of the following changes and new
 539   APIs:</p>
 540
 541 <ul>
 542   <li><tt>svn_opt_parse_path()</tt> changes
 543     <ul>
 544       <li>
 545         Since Subversion 1.3, if a path or URL ends in an empty
 546         revision suffix '@', then the returned revision type would be
 547         different than an unprotected path or URL:
 548         <ul>
 549           <li>
 550             <tt>some/path/to/foo</tt> returns
 551             <tt>svn_opt_revision_unspecified</tt>
 552           </li>
 553           <li>
 554             <tt>some/path/to/foo<b>@</b></tt> returns
 555             <tt>svn_opt_revision_base</tt>
 556           </li>
 557           <li>
 558             <tt>http://example.com/some/path/to/foo</tt> returns
 559             <tt>svn_opt_revision_unspecified</tt>
 560           </li>
 561           <li>
 562             <tt>http://example.com/some/path/to/foo@</tt> returns
 563             <tt>svn_opt_revision_head</tt>
 564           </li>
 565         </ul>
 566         Subversion 1.5 fixes this inconsistency, all the above paths
 567         and URLs return <tt>svn_opt_revision_unspecified</tt>.
 568       </li>
 569       <li>
 570         Since Subversion 1.2, <tt>svn_opt_parse_path</tt> would always
 571         canonicalize the returned path or URL with
 572         <tt>svn_path_canonicalize</tt>, even though this is not
 573         documented in <tt>subversion/include/svn_opt.h</tt>.  For the
 574         relative externals support, uncanonicalized paths need to be
 575         returned, otherwise scheme relative URLs,
 576         i.e. <tt>//example.com/some/path</tt> would be canonicalized
 577         to server root relative URLs <tt>/example.com/some/path</tt>.
 578         Users of this function now must ensure that they canonicalize
 579         the result of this function if they pass it to any other
 580         Subversion functions that expect a canonicalized path or URL.
 581       </li>
 582     </ul>
 583   </li>
 584
 585   <li>XXX: Enumerate specific new API additions (e.g. merge info
 586     retrieval?)</li>
 587
 588   <li>APIs backing the new <a href="#cmdline">Command-line client
 589     improvements</a> section have been added.</li>
 590
 591   <li>Many APIs have been revised to newer versions.</li>
 592
 593   <li>Language bindings expanded and improved</li>
 594 </ul>
 595
 596 </div>  <!-- apis -->
 597
 598 <div class="h3" id="dav-modules" title="dav-modules">
 599 <h3>Easier to try out experimental <tt>ra_serf</tt> DAV access module
 600 (<em>client</em>)</h3>
 601
 602 <p>Subversion 1.4 introduced the experimental <tt>ra_serf</tt>
 603 repository access module for accessing HTTP[S] DAV Subversion servers.
 604 This uses the <a href="http://code.google.com/p/serf/">serf</a>
 605 library instead of the Neon library which the original DAV support
 606 uses.  serf supports pipelined requests which may lead to better
 607 performance.  However, Subversion 1.4 required you to choose which
 608 module to use for accessing DAV servers at build time, which made it
 609 difficult to find out which module performs better for your usage
 610 patterns.</p>
 611
 612 <p>Subversion 1.5 allows you to build both modules at the same time;
 613 you can choose which library to use on a global or host-by-host basis
 614 by setting the <tt>http-library</tt> variable in your run-time server
 615 configuration file (<tt>~/.subversion/servers</tt>).  In recognition
 616 of the fact that both libraries are DAV clients, we have
 617 renamed <tt>ra_dav</tt> to <tt>ra_neon</tt>.</p>
 618
 619 </div>  <!-- dav-modules -->
 620
 621 <div class="h3" id="bug-fixes" title="bug-fixes">
 622 <h3>Other bug fixes (<em>client and server</em>)</h3>
 623
 624 <p>The usual slew of heretofore-unreleased bug fixes, more than 40
 625 overall. See the
 626 <a href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a>
 627 file for full details.</p>
 628
 629 </div>  <!-- bug-fixes -->
 630
 631 </div>  <!-- enhancements -->
 632
 633 <div class="h2" id="svn-1.3-deprecation" title="svn-1.3-deprecation">
 634 <h2>Subversion 1.3.x series no longer supported</h2>
 635
 636 <p>The Subversion 1.3.x line is no longer supported.  This doesn't
 637 mean that your 1.3 installation is doomed; if it works well and is all
 638 you need, that's fine.  "No longer supported" just means we've stopped
 639 accepting bug reports against 1.3.x versions, and will not make any
 640 more 1.3.x bugfix releases, except perhaps for absolutely critical
 641 security or data-loss bugs.</p>
 642
 643 </div>  <!-- svn-1.3-deprecation -->
 644
 645 </div>  <!-- app -->
 646 </body>
 647 </html>