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 class="h3" id="sasl-compatibility" title="sasl-compatibility">
 132 <h3>SASL and <code>svn://</code> compatibility</h3>
 133
 134 <p>All 1.x clients, with or without Cyrus SASL support, will be able to
 135 authenticate against all 1.x servers that do not have Cyrus SASL enabled.
 136 Note that the <tt>CRAM-MD5</tt> and <tt>ANONYMOUS</tt> mechanisms are
 137 actually built into Subversion, so you'll be able to use them even if the
 138 corresponding Cyrus SASL plugins are missing.</p>
 139
 140 <p>1.x clients without Cyrus SASL support will be able to authenticate
 141 against 1.5+ servers with SASL enabled, provided the server allows the
 142 <tt>CRAM-MD5</tt> and/or <tt>ANONYMOUS</tt> mechanisms.</p>
 143
 144 <p>1.5+ clients with Cyrus SASL support will be able to authenticate against
 145 1.5+ servers with SASL enabled, provided at least one of the mechanisms
 146 supported by the server is also supported by the client.</p>
 147
 148 </div>  <!-- sasl-compatibility -->
 149
 150 </div>  <!-- compatibility -->
 151
 152 <div class="h2" id="new-features" title="new-features">
 153 <h2>New Features</h2>
 154
 155 <p>XXX: Describe each new feature.  See the 1.4 RNs for a
 156 "template".</p>
 157
 158 <div class="h3" id="merge-tracking" title="merge-tracking">
 159 <h3>Merge Tracking (<em>client and server</em>)</h3>
 160
 161 <p>XXX</p>
 162
 163 </div> <!-- merge-tracking -->
 164
 165 <div class="h3" id="sparse-checkouts" title="sparse-checkouts">
 166 <h3>Sparse checkouts (<em>client and server</em>)</h3>
 167
 168 <p>Many users have very large trees of which they only want to checkout
 169 certain parts.  In previous versions of Subversion, <code>checkout -N</code>
 170 was not today up to this task.  Subversion 1.5 introduces the
 171 <code>--depth</code> option to the <code>checkout</code>, <code>switch</code>,
 172 and <code>update</code> subcommands as a replacement for <code>-N</code>, which
 173 allows working copies to have very specific contents, leaving out everything
 174 the user does not want.</p>
 175
 176 <div class="h4" id="sc-depth" title="sc-depth">
 177 <h4>Depth</h4>
 178 <p>Each directory now understands the notion of <em>depth</em>, which has
 179 four possible values: <tt>empty</tt>, <tt>depth-files</tt>, <tt>immediates</tt>,
 180 <tt>infinity</tt>.  The values are defined as follows:</p>
 181
 182 <table>
 183 <tr>
 184   <td>empty</td>
 185   <td>Updates will not pull in any files or subdirectories not already
 186     present.</td>
 187 </tr>
 188 <tr>
 189   <td>files</td>
 190   <td>Updates will pull in any files not already present, but not
 191     subdirectories.</td>
 192 </tr>
 193 <tr>
 194   <td>immediates</td>
 195   <td>Updates will pull in any files or subdirectories not already present;
 196     those subdirectories' will have depth-empty.</td>
 197 </tr>
 198 <tr>
 199   <td>infinity</td>
 200   <td>Updates will pull in any files or subdirectories not already present;
 201     those subdirectories' will have depth-infinity.  Equivalent to today's
 202     default update behavior.</td>
 203 </tr>
 204 </table>
 205
 206 <p>The <code>--depth</code> option sets depth values as it updates the working
 207 copy, setting any new subdirectories' depth values as described above.</p>
 208
 209 </div>  <!-- sc-depth -->
 210
 211 <div class="h4" id="sc-ui" title="sc-ui">
 212 <h4>User Interface</h4>
 213 <p>Affected commands:</p>
 214 <ul>
 215   <li><code>checkout</code></li>
 216   <li><code>switch</code></li>
 217   <li><code>update</code></li>
 218   <li><code>status</code></li>
 219   <li><code>info</code></li>
 220 </ul>
 221
 222 <p>The <code>-N</code> option becomes a synonym for <code>--depth=files</code>
 223 for these commands.  This changes the existing <code>-N</code> behavior for
 224 these commands, but in a trivial way (see below).</p>
 225
 226 <p><code>checkout</code> without <code>--depth</code> or <code>-N</code>
 227 behaves the same as it does today.  <code>switch</code> and <code>update</code>
 228 without <code>--depth</code> or <code>-N</code> behave the same way as today
 229 IFF the working copy is fully depth-infinity.  <code>switch</code> and
 230 <code>update</code> without <code>--depth</code> or <code>-N</code> will
 231 <strong>not</strong> change depth values (exception: a missing directory
 232 specified on the command line will be pulled in).</p>
 233
 234 <p>Thus, <code>checkout</code> is identical to <code>checkout
 235 --depth=infinity</code>, but <code>switch</code> and <code>update</code> are
 236 not the same as <code>switch --depth=infinity</code> and <code>update
 237 --depth=infinity</code>.  The former update entries according to existing depth
 238 values, while the latter pull in everything.</p>
 239
 240 <p>To get started, run <code>checkout</code> with <code>--depth=empty</code>
 241 or <code>--depth=files</code>.  If additional files or directories are desired,
 242 pull them in with <code>update</code> commands using appropriate
 243 <code>--depth</code> options.</p>
 244
 245 <p>The <code>svn status</code> should list the depth status of the directories,
 246 in addition to whatever statuses are being currently listed.</p>
 247
 248 <p>The <code>svn info</code> command should list the depth, iff invoked on a
 249 directory whose depth is not the default (depth-infinity)</p>
 250
 251 </div>  <!-- sc-ui -->
 252
 253 <div class="h4" id="sc-compat" title="sc-compat">
 254 <h4>Compatibility with older servers</h4>
 255 <p>This feature introduces two new concepts into the repository access
 256 protocol which will not be understood by older servers:</p>
 257 <ul>
 258   <li>Reported Depths &mdash; the depths associated with individual paths
 259     included by the client in the description of its working copy state.</li>
 260   <li>Requested Depth &mdash; the single depth value used to limit the
 261     scope of the server's response to the client.</li>
 262 </ul>
 263
 264 <p>As such, it's useful to understand how these concepts will be handled
 265 across the compatibility matrix of depth-aware and non-depth-aware clients and
 266 servers.</p>
 267
 268 <div class="h5" id="sc-compat-dac" title="sc-compat-dac">
 269 <h5>Depth-aware Clients (DACs)</h5>
 270 <p>DACs will transmit reported depths (with "infinity" as the default) and will
 271 transmit a requested depth (with "unknown" as the default).  They will also
 272 &mdash; for the sake of older, non-depth-aware servers (NDASs) -- transmit a
 273 requested recurse value derived from the requested depth:</p>
 274 <table>
 275 <tr><th>depth</th><th>recurse</th></tr>
 276 <tr><td>empty</td><td>no</td></tr>
 277 <tr><td>files</td><td>no</td></tr>
 278 <tr><td>unknown</td><td>yes</td></tr>
 279 <tr><td>immediates</td><td>yes</td></tr>
 280 <tr><td>infinity</td><td>yes</td></tr>
 281 </table>
 282
 283 <p>When speaking to an NDAS, the requested recurse value is the only thing
 284 the server understands , but is obviously more "grainy" than the requested
 285 depth concept.  The DAC, therefore, must filter out any additional, unwanted
 286 data that the server transmits in its response.  (This filtering happens in
 287 the repository access implementation itself so the repository access APIs
 288 behave as expected regardless of the server's pedigree.)</p>
 289
 290 <p>When speaking to a depth-aware server (DAS), the requested recurse value
 291 is ignored.  A requested depth of "unknown" means "only send information about
 292 the stuff in my report, depth-aware-ily".  Other requested depth values are
 293 honored by the server properly, and the DAC must handle the transformation of
 294 any working copy depths from their pre-update to their post-update depths and
 295 content.</p>
 296
 297 </div>  <!-- sc-compat-dac -->
 298
 299 <div class="h5" id="sc-compat-ndac" title="sc-compat-ndac">
 300 <h5>Non-depth-aware Clients (NDACs)</h5>
 301
 302 <p>NDACs will never transmit reported depths and never transmit a requested
 303 depth.  But they will transmit a requested recurse value (either "yes" or "no",
 304 with "yes" being the default).</p>
 305
 306 <p>When speaking to an NDAS, what happens happens.  It's the past, man &mdash;
 307 you don't get to define the interaction this late in the game!</p>
 308
 309 <p>When speaking to a DAS, the not-reported depths are treated like reported
 310 depths of "infinity", and the reported recurse values "yes" and "no" map to
 311 depths of "infinity" and "files", respectively.</p>
 312
 313 </div>  <!-- sc-compat-dac -->
 314
 315 </div>  <!-- sc-compat -->
 316
 317 <p>Sparse checkouts are further described <a
 318 href="http://svn.collab.net/repos/svn/trunk/notes/sparse-directories.txt"
 319 >in the repository</a>.</p>
 320
 321 </div> <!-- sparse-checkouts -->
 322
 323 <div class="h3" id="conflict-resolution" title="conflict-resolution">
 324 <h3>Interactive Conflict Resolution (<em>client</em>)</h3>
 325
 326 <p>Added support for interactive conflict resolution in the command
 327 line client, and a corresponding callback function in the client
 328 library.  GUI clients can use the callback function to hook in a
 329 graphical conflict resolution program to the
 330 <code>update</code>/<code>switch</code>/<code>merge</code>
 331 sub-commands.  Example command line output:</p>
 332 <pre>
 333     $ svn up
 334     U    contrib/client-side/svnmerge/svnmerge_test.py
 335     Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
 336     Select: (p)ostpone, (d)iff, (e)dit, (h)elp : h
 337       (p)ostpone - mark the conflict to be resolved later
 338       (d)iff     - show all changes made to merged file
 339       (e)dit     - change merged file in an editor
 340       (r)esolved - accept merged version of file
 341       (m)ine     - accept my version of file
 342       (t)heirs   - accept repository's version of file
 343       (l)aunch   - use third-party tool to resolve conflict
 344       (h)elp     - show this list
 345
 346     Select: (p)ostpone, (d)iff, (e)dit, (h)elp : t
 347     G    contrib/client-side/svnmerge/svnmerge.py
 348     Updated to revision 25685.
 349 </pre>
 350 <p>This feature can be selectively disabled by using the --non-interactive
 351 option, or disabled permanently by setting '[miscellany] interactive-conflicts
 352  = no' in your run-time config file.</p>
 353
 354 <p>The API for interactive conflict resolution is exposed via a
 355 callback function and the following new data types:</p>
 356
 357 <ul>
 358   <li><code>svn_wc_conflict_resolver_func_t</code>, the callback API
 359     itself</li>
 360   <li><code>svn_wc_conflict_description_t</code>, a description of the
 361     conflict passed to the callback</li>
 362   <li><code>svn_wc_conflict_action_t</code>, the part of the conflict
 363     description indicating what the merge was trying to do</li>
 364   <li><code>svn_wc_conflict_reason_t</code>, the part of the conflict
 365     description indicating the type of conflict</li>
 366   <li><code>svn_wc_conflict_result_t</code>, returned by the callback
 367     as the result of any conflict resolution attempt</li>
 368 </ul>
 369
 370 <p>Clients provide their callback function to Subversion's libraries
 371 by setting it on the (new) <code>conflict_func</code> field of their
 372 <code>svn_client_ctx_t</code>, and may provide additional state to the
 373 callback via the corresponding <code>conflict_baton</code> field.</p>
 374
 375 </div>  <!-- conflict-resolution -->
 376
 377 <div class="h3" id="webdav-proxy" title="webdav-proxy">
 378 <h3>WebDAV transparent write-through proxy (<em>server</em>)</h3>
 379
 380 <p>Subversion 1.4 <a
 381 href="http://subversion.tigris.org/svn_1.4_releasenotes.html#svnsync">
 382 introduced <tt>svnsync</tt></a>&mdash;a tool which provided the ability to
 383 replicate repository history from one repository to another.  Though useful,
 384 <tt>svnsync</tt> could only pull revision history from a repository, not push
 385 additional commits back to the master.  Subversion 1.5 adds WebDAV proxy
 386 support to <tt>mod_dav_svn</tt>, effectly allowing bidirectional revision
 387 history replication between master servers and slave servers using
 388 <tt>mod_dav_svn</tt>.</p>
 389
 390 <p>All clients interact with a slave server, but the slave transparently
 391 passes all of the write-oriented activites to the master (rewriting the
 392 content as necessary).  The slaves are essentially read-only, but they
 393 do have a complete copy of the repository locally.  This serves to
 394 alleviate read traffic from the master server which may be desirable
 395 in certain circumstances.</p>
 396
 397 <p>This model has several advantages to using a straight HTTP DAV-aware
 398 caching proxy, in that each slave can respond to all read-only requests
 399 without ever having to relay them to the master backend.</p>
 400
 401 <div class="h4" id="webdav-proxy-requirements"
 402     title="webdav-proxy-requirements">
 403 <h4>Requirements</h4>
 404 <ul>
 405   <li>Subversion 1.5 or newer.</li>
 406   <li>Apache HTTP Server 2.2.0 or higher with mod_proxy enabled.
 407     (Several fixes to mod_proxy were committed for this patch that were not
 408     backported to the 2.0 branch of httpd.)</li>
 409 </ul>
 410
 411 </div>  <!-- webdav-proxy-requirements -->
 412
 413 <div class="h4" id="webdav-proxy-example" title="webdav-proxy-example">
 414 <h4>Example configuration</h4>
 415
 416 <p>Participants:</p>
 417 <ul>
 418   <li>Slave &rarr; <tt>slave.example.com</tt>  (there can be many!)</li>
 419   <li>Master &rarr; <tt>master.example.com</tt> (there can only be one!)</li>
 420   <li>A WebDAV client (<tt>ra_neon</tt>, <tt>ra_serf</tt>, other WebDAV
 421     clients)</li>
 422 </ul>
 423
 424 <p>Each client does:</p>
 425 <pre><code>
 426     % svn co http://slave.example.com/repos/slave/
 427     ...
 428     % svn ci
 429     % ...etc...
 430 </code></pre>
 431 <p>(The client can perform all operations as normal.)</p>
 432
 433 <p>Each slave has:</p>
 434 <pre><code>
 435     &lt;Location /repos/slave&gt;
 436       DAV svn
 437       SVNPath /my/local/copy/of/repos
 438       SVNMasterURI http://master.example.com/repos/master
 439     &lt;/Location&gt;
 440 </code></pre>
 441
 442 <p>The master MUST have a post-commit hook that updates all of the slaves.  An
 443 example that does this using <code>svnadmin dump</code>/<code>svnadmin
 444 load</code> and ssh is provided below.  <tt>svnsync</tt> can probably do the
 445 same thing (XXX: we should probably answer this question more confidently).</p>
 446
 447 <p>Additionally, if locks are permitted on the master repository, lock databases
 448 need to kept in sync via post-lock and post-unlock hooks on the master pushing
 449 the lock state to the slaves.  (Username preservation is left as an exercise to
 450 the reader.)(XXX: Same as above.)  If the lock database is not propogated, users
 451 will not be able to accurately determine whether a lock is held - but locking
 452 will still work.</p>
 453
 454 <p>A sample synchronization script may look like this:</p>
 455 <pre><code>
 456     #!/bin/sh
 457     REPOS="$1"
 458     REV="$2"
 459     SLAVE_HOST=slave.example.com
 460     SLAVE_PATH=/my/local/copy/of/repos
 461
 462     # Ensure svnadmin is in your PATH on both this machine and the remote server!
 463     svnadmin dump --incremental -r$2 $1 &gt; /tmp/$2.dump
 464     scp /tmp/$2.dump $SLAVE_HOST:$SLAVE_PATH
 465     ssh $SLAVE_HOST "svnadmin load $SLAVE_PATH &lt; $SLAVE_PATH/$2.dump"
 466     ssh $SLAVE_HOST "rm $SLAVE_PATH/$2.dump"
 467     rm /tmp/$2.dump
 468 </code></pre>
 469
 470 </div>  <!-- webdav-proxy-example -->
 471
 472 <p>Additional information about WebDAV proxy support is available <a
 473 href="http://svn.collab.net/repos/svn/trunk/notes/webdav-proxy">in the
 474 repository</a>.</p>
 475
 476 </div>  <!-- webdav-proxy -->
 477
 478 <div class="h3" id="cyrus-sasl" title="cyrus-sasl">
 479 <h3>Cyrus SASL support for ra_svn and <tt>svnserve</tt> (<em>client
 480 and server</em>)</h3>
 481
 482 <p>From <a
 483 href="http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer">
 484 Wikipedia</a>: SASL is a framework for authentication and data security in
 485 Internet protocols.  It decouples authentication mechanisms from application
 486 protocols, in theory allowing any authentication mechanism supported by SASL to
 487 be used in any application protocol that uses SASL."</p>
 488
 489 <p>In practice, the server sends a list of authentication mechanisms that it
 490 supports.  The client then selects one of these mechanisms based on what the
 491 client supports, and informs the server of its decision.  After that, a
 492 number of messages are exchanged until either authentication succeeds or an
 493 error occurs.  In the latter case, the client is allowed to restart
 494 authentication.</p>
 495
 496 <p>The <tt>svn://</tt> protocol has always supported this type of negotiation.
 497 However, only the <tt>CRAM-MD5</tt> and <tt>ANONYMOUS</tt> mechanisms were
 498 implemented.  <a href="http://asg.web.cmu.edu/sasl/">Cyrus SASL</a> supports
 499 all these, and, in addition, provides a host of other mechanisms such as
 500 <tt>DIGEST-MD5</tt>, OTP (One-Time Passwords), GSSAPI (used for Kerberos
 501 authentication), NTLM (NT LAN Manager), SRP (Secure Remote Password), and
 502 others.  The exact list of available mechanisms depends on how SASL was
 503 compiled, as many of them either have external dependencies, or are not
 504 built by default.  Also, because each mechanism is actually a shared library
 505 that is dynamically loaded at runtime, many distributions package these
 506 mechanisms separately from the core library.</p>
 507
 508 <p>Please see the <a href="#sasl-compatibility">compatibility section</a> for
 509 information regarding using a 1.5 SASL-enabled server with pre-1.5 clients.
 510 More information about Subversion's SASL support can be found <a
 511 href="http://svn.collab.net/repos/svn/trunk/notes/sasl.txt">in the
 512 repository</a>.</p>
 513
 514 </div> <!-- cyrus-sasl -->
 515
 516 <div class="h3" id="changelist-support" title="changelist-support">
 517 <h3>Changelist support (<em>client</em>)</h3>
 518 <p>The Subversion client now contains the notion of a <em>changelist</em>:
 519 a group of files which are associated with a chosen name.  This becomes
 520 especially useful when working on several different set of files within the
 521 same working copy.  Instead of having to remember each file in each set,
 522 Subversion 1.5 will allow you to associate a changelist with each set of
 523 files.  Most commands which take a set of files as targets will now also
 524 accept the <code>--changelist</code> option, which filters those targets
 525 based upon the members of the changelist.  Changelist membership can be
 526 edited using the new <code>changelist</code> subcommand.</p>
 527
 528 <p>Changelists are handled entirely by the client.  They are never sent
 529 to the server, and aren't visible to other users of the same repository.
 530 Also, the <code>--changelist</code> option is never additive; if a file
 531 wouldn't have been included in the list of targets with out
 532 <code>--changelist</code>, it will not be added to it, regardless of membership
 533 in the changelist.  Currently, a file may only be in one changelist at a
 534 time, and directories can not be members of a changelist.</p>
 535
 536 <p>The <code>--changelist</code> option is supported by the following
 537 subcommands:</p>
 538 <ul>
 539   <li><code>changelist</code></li>
 540   <li><code>commit</code></li>
 541   <li><code>diff</code> (only wc-wc and wc-repos cases)</li>
 542   <li><code>info</code></li>
 543   <li><code>propget</code></li>
 544   <li><code>proplist</code></li>
 545   <li><code>propset</code></li>
 546   <li><code>propdel</code></li>
 547   <li><code>revert</code></li>
 548   <li><code>status</code></li>
 549   <li><code>update</code><li>
 550 </ul>
 551
 552 <p>More information about changelists can be found <a
 553 href="http://svn.collab.net/repos/svn/trunk/notes/changelist-design.txt"
 554 >here</a>.</p>
 555
 556 </div>  <!-- changelist-support -->
 557
 558 <div class="h3" id="relative-externals" title="relative-externals">
 559 <h3>Relative peg URLs in <tt>svn:externals</tt> (<em>client</em>)</h3>
 560
 561 <p>Two additions to the <tt>svn:externals</tt> feature</p>
 562   <ul>
 563     <li>
 564       <p>
 565         The URLs may include peg specifications.  Because the
 566         directory a URL refers to with and without a peg revision uses
 567         a different lookup and result in different contents, the
 568         current format from older versions of Subversion continues to
 569         not understand peg revisions.  A new format is introduced to
 570         allow peg revisions in URLs.
 571       </p>
 572       <p>So the old format of</p>
 573         <pre>
 574           foo             http://example.com/repos/zig
 575           foo/bar -r 1234 http://example.com/repos/zag
 576         </pre>
 577         <p>does not support peg revisions.  In fact, these following
 578         externals will not work unless there are directories named
 579         <tt>zig@HEAD</tt> and <tt>zag@HEAD</tt>:</p>
 580         <pre>
 581           foo             http://example.com/repos/zig@HEAD
 582           foo/bar -r 1234 http://example.com/repos/zag@HEAD
 583         </pre>
 584       <p>
 585         The new format moves the URL first followed by the directory
 586         the external is checked out or exported into</p>
 587         <pre>
 588           http://example.com/repos/zig foo1
 589           -r 1234 http://example.com/repos/zag foo/bar1
 590           http://example.com/repos/zig@HEAD foo2
 591           -r 1234 http://example.com/repos/zag@HEAD foo/bar2
 592         </pre>
 593         <p>peg specifications are allowed but not necessary.
 594       </p>
 595     </li>
 596     <li>
 597       <p>
 598         Up to Subversion 1.4, the URLs in an <tt>svn:externals</tt>
 599         specification must be absolute.  Now they can be relative.
 600         Four different relative externals are supported.
 601       </p>
 602       <p>
 603         For the following example, assume we have two repositories at
 604         <tt>http://example.com/svn/repos-1</tt> and
 605         <tt>http://example.com/svn/repos-2</tt>.  We have a checkout
 606         of <tt>http://example.com/svn/repos-1/project1/trunk</tt> and
 607         the <tt>svn:external</tt> property is set on <tt>trunk</tt>.</p>
 608         <ul>
 609           <li>
 610             <tt>../</tt>
 611             <br/>
 612             Relative to the directory with the <tt>svn:external</tt>
 613             property.  These URLs always begin with the string
 614             <tt>../</tt>.
 615             <pre>
 616               ../../project2/trunk common/project2/trunk
 617             </pre>
 618             This will extract
 619             <tt>http://example.com/svn/repos-1/project2/trunk</tt>
 620             into <tt>common/project2/trunk</tt>.  The URL is relative
 621             to the directory with the <tt>svn:external</tt>, not the
 622             directory where the external is written to disk.
 623           </li>
 624           <li>
 625             <tt>^/</tt>
 626             <br/>
 627             Relative to the repository root.
 628             <pre>
 629               ^/project2/trunk common/project2/trunk
 630             </pre>
 631             This will extract
 632             <tt>http://example.com/svn/repos-1/project2/trunk</tt>
 633             into <tt>common/project2/trunk</tt>.
 634             <br/>
 635
 636             You can also refer to other repositories easily using
 637             repository root relative URLs:
 638             <pre>
 639               ^/../repos-2/foo/trunk common/foo/trunk
 640             </pre>
 641             This will extract
 642             <tt>http://example.com/svn/repos-2/foo/trunk</tt> into
 643             <tt>common/foo/trunk</tt>
 644           </li>
 645           <li>
 646             <tt>//</tt>
 647             <br/>
 648             Relative to the scheme.  This copies the scheme of the
 649             checkout or export URL into the URL in the
 650             <tt>svn:external</tt>.  It is useful when the same
 651             hostname must the accessed with different scheme's
 652             depending upon network location; i.e. clients in the
 653             intranet use <tt>http://</tt> while external clients use
 654             <tt>svn+ssh://</tt>.
 655             <pre>
 656               //example.com/svn/repos-1/project2/trunk common/project2/trunk
 657             </pre>
 658             This will extract
 659             <tt>http://example.com/svn/repos-1/project2/trunk</tt>
 660             into <tt>common/project2/trunk</tt>.  If the working copy
 661             was checked out from
 662             <tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt>
 663             then this URL would be
 664             <tt>http://example.com/svn/repos-1/project1/trunk</tt>.
 665           </li>
 666           <li>
 667             <tt>/</tt>
 668             <br/>
 669
 670             Server root relative URLs.  This copies the scheme and
 671             hostname from the checkout or export URL into the
 672             <tt>svn:external</tt> URL.
 673             <pre>
 674               /svn/repos-1/project2/trunk common/project2/trunk
 675             </pre>
 676             This will extract
 677             <tt>http://example.com/svn/repos-1/project2/trunk</tt>
 678             into <tt>common/project2/trunk</tt>.  If the working copy
 679             was checked out from
 680             <tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt>
 681             then this URL would be
 682             <tt>http://example.com/svn/repos-1/project1/trunk</tt>.
 683           </li>
 684         </ul>
 685       <p>
 686         Relative URLs are supported in the old <tt>svn:externals</tt>
 687         format that do not support peg revisions.
 688       </p>
 689       <p>
 690         When Subversion sees an <tt>svn:externals</tt> without an
 691         absolute URL it takes the first argument as a relative URL and
 692         the second as the target directory.
 693       </p>
 694     </li>
 695   </ul>
 696
 697 </div>  <!-- relative-externals -->
 698
 699 <div class="h3" id="fsfs-sharding" title="fsfs-sharding">
 700 <h3>FSFS sharding (<em>server</em>)</h3>
 701
 702 <p>The FSFS filesystem backend stores each revision in its own file, and prior
 703 to Subversion 1.5, all of these files were stored in a common directory in
 704 the repository.  Now, <em>newly created</em> FSFS repositories will use a
 705 two-level directory tree with up to (by default) 1000 files per directory.
 706 These repositories will only be compatible with other Subversion 1.5 clients,
 707 but of course, Subversion 1.5 will be able to continue using repositories
 708 employing the older scheme without any problem.</p>
 709
 710 <p>The primary reason for the change is to help support filesystems with
 711 less-than-ideal large directory entry count performance.  In addition,
 712 certain third-party tools may work better with a sharded layout versus
 713 an unsharded one.</p>
 714
 715 <p>For more information about the technical underpinnings of FSFS sharding,
 716 see this <a href="http://www.farside.org.uk/200704/tree_structured_fsfs">blog
 717 entry</a>.
 718 <!-- ### Reshard script is not quite finished and currently
 719      ### aborts if you try to run it.
 720  <a
 721  href="http://svn.collab.net/repos/svn/trunk/tools/server-side/fsfs-reshard.py"
 722  >Migration script</a> provided.
 723 -->
 724 </p>
 725
 726 </div>  <!-- fsfs-sharding -->
 727
 728 </div>  <!-- new-features -->
 729
 730
 731 <div class="h2" id="enhancements" title="enhancements">
 732 <h2>Enhancements and Bugfixes</h2>
 733
 734 <div class="h3" id="copy-move-improvements" title="copy-move-improvements">
 735 <h3>Copy/move-related improvements (<em>client and server</em>)</h3>
 736
 737 <p>The abilities and behavior of <code>copy</code> and
 738 <code>move</code> operations has improved significantly.</p>
 739
 740
 741 <div class="h4" id="leverage-copyfrom" title="leverage-copyfrom">
 742 <h4>Improved copy-handling during updates (<em>client and server</em>)</h4>
 743
 744 <p>A common problem in older versions of Subversion was the way in
 745 which <code>svn update</code> handled incoming copies and moves.</p>
 746
 747 <p>For example, suppose Harry runs <code>svn move foo bar; svn
 748 commit</code>, and meanwhile Sally makes local changes to 'foo', and
 749 then runs <code>svn update</code>.  In earlier versions of Subversion,
 750 the server would send down a completely new file 'bar', and remove the
 751 file 'foo' (or rather, make it unversioned, since it has uncommitted
 752 changes.)  From Sally's point of view, her changes seem to be lost;
 753 the newly added 'bar' file has the older content.  In Subversion 1.5,
 754 the client and server both attempt to be smarter about this.  The
 755 server doesn't send a whole new file during the update, but rather
 756 instructions to copy something that may likely already exists in the
 757 working copy.  So Sally's 'foo' file is copied to 'bar' (with local
 758 edits intact!).</p>
 759
 760 <p>In theory, this is the best-case scenario.  There are a few
 761 caveats: this "proper copying" of existing working-copy resources only
 762 works on files, not (yet) on directories.  Also, if an incoming
 763 move-operation deletes 'foo' before it attempts to copy it to 'bar',
 764 then the copy will fail, and the client reverts to the old behavior of
 765 fetching a pristine copy of the file from the repository.  We hope to
 766 address this in svn 1.6.  For details on the this issue see <a
 767 href="http://subversion.tigris.org/issues/show_bug.cgi?id=503">issue
 768 #503</a>.</p>
 769
 770 </div> <!-- leverage-copyfrom -->
 771
 772 <div class="h4" id="copy-peg-revs" title="copy-peg-revs">
 773 <h4>Peg revisions (<em>client</em>)</h4>
 774
 775 <p>Copy operations now accept sources with peg revisions.</p>
 776
 777 </div>  <!-- copy-peg-revs -->
 778
 779 <div class="h4" id="multi-op-copy-move" title="multi-op-copy-move">
 780 <h4>Multiple working copy copy/move operations (<em>client</em>)</h4>
 781
 782 <p>Clients may now perform multiple local copy/move operations on a
 783 single object in a working copy:</p>
 784 <blockquote><pre><code>
 785 svn mv path1 path2
 786 svn mv path2 path3
 787 </code></pre></blockquote>
 788
 789 </div>  <!-- multi-op-copy-move -->
 790
 791 <div class="h4" id="multi-src-copy" title="multi-src-copy">
 792 <h4>Improved handling multiple copy/move sources (<em>client</em>)</h4>
 793
 794 <p>Clients now accept multiple sources for copy and move operations, with
 795 the ability to copy/move each of the sources to the specified directory.
 796 This mirrors the behavior of standard command-line copy and move tools,
 797 such as <code>cp</code> and <code>mv</code>.  In practice, this means
 798 users can take advantage of shell globbing when doing a local copy
 799 or move:</p>
 800 <blockquote><pre><code>
 801 svn cp *.c dir
 802 </code></pre></blockquote>
 803
 804 <p>Multiple source copy/move also works for all previously defined
 805 copy/move working copy and repository combinations.  This was
 806 <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=747">issue
 807 #747</a>.</p>
 808
 809 </div>  <!-- multi-src-copy -->
 810
 811 </div>  <!-- copy-move-improvements -->
 812
 813 <div class="h3" id="cancellation-improvements"
 814      title="cancellation-improvements">
 815 <h3>Cancellation improvements (<em>client</em>)</h3>
 816
 817 <p>Clients operations are now significantly more responsive to
 818 cancellation (e.g. via <tt>control-c</tt>).  In pre-1.5 releases,
 819 after directing an operation to stop, one sometimes had to wait for
 820 some time (e.g. while I/O occurred) before the operation would
 821 actually stop.</p>
 822
 823 </div>  <!-- cancellation-improvements -->
 824
 825 <div class="h3" id="cmdline" title="cmdline">
 826 <h3>Command-line client improvements (<em>client</em>)</h3>
 827
 828 <ul>
 829   <li>A <code>--use-merge-history</code> option to adhere to Merge
 830     Tracking meta data has been added to the following sub-commands:
 831     <ul>
 832       <!-- li>blame</li -->
 833       <li>log</li>
 834       <li>merge</li>
 835     </ul>
 836   </li>
 837
 838   <li>A <code>--parents</code> option to create intermediate
 839     directories has been added to the following sub-commands:
 840     <ul>
 841       <li>add</li>
 842       <li>copy</li>
 843       <li>move</li>
 844       <li>mkdir</li>
 845     </ul>
 846   </li>
 847
 848   <!-- ### Anticipated addition(s):
 849        ### double-dash sequences inside comment changed to '++' to
 850        ### avoid breaking XML rules.
 851   <li><code>++merged-from</code> and <code>++merged-to</code> options
 852     to report on merge info have been added to the <code>info</code>
 853     sub-command.</li>
 854
 855   <li>An <code>++accept=orig|mine|repo</code> option to select which
 856     version of a path to retain has been added to the
 857     <code>resolved</code> sub-command.</li>
 858   -->
 859
 860   <li>A <code>--keep-local</code> option to retain paths locally has
 861     been added to the <code>delete</code> sub-command.</li>
 862
 863   <li>A <code>--depth</code> option has been added to support <a
 864     href="#sparse-checkouts">sparse checkouts</a>.  <code>-N</code> is now
 865     maps to one of the arguments for <code>--depth</code>, depending on
 866     context.</li>
 867
 868   <li>As part of the <a href="#sparse-checkouts">sparse checkouts</a> work,
 869     <code>-R</code> is now just a synonym for <code>--depth=infinity</code>.
 870     </li>
 871 </ul>
 872
 873 <p>XXX: More...</p>
 874
 875 </div>  <!-- cmdline -->
 876
 877 <div class="h3" id="apis" title="apis">
 878 <h3>API changes, improvements and language bindings
 879     (<em>client and server</em>)</h3>
 880
 881 <p>If you develop a 3rd-party client application that uses Subversion
 882   APIs, you may want to take notice of the following changes and new
 883   APIs:</p>
 884
 885 <ul>
 886   <li><tt>svn_opt_parse_path()</tt> changes
 887     <ul>
 888       <li>
 889         Since Subversion 1.3, if a path or URL ends in an empty
 890         revision suffix '@', then the returned revision type would be
 891         different than an unprotected path or URL:
 892         <ul>
 893           <li>
 894             <tt>some/path/to/foo</tt> returns
 895             <tt>svn_opt_revision_unspecified</tt>
 896           </li>
 897           <li>
 898             <tt>some/path/to/foo<b>@</b></tt> returns
 899             <tt>svn_opt_revision_base</tt>
 900           </li>
 901           <li>
 902             <tt>http://example.com/some/path/to/foo</tt> returns
 903             <tt>svn_opt_revision_unspecified</tt>
 904           </li>
 905           <li>
 906             <tt>http://example.com/some/path/to/foo@</tt> returns
 907             <tt>svn_opt_revision_head</tt>
 908           </li>
 909         </ul>
 910         Subversion 1.5 fixes this inconsistency, all the above paths
 911         and URLs return <tt>svn_opt_revision_unspecified</tt>.
 912       </li>
 913       <li>
 914         Since Subversion 1.2, <tt>svn_opt_parse_path</tt> would always
 915         canonicalize the returned path or URL with
 916         <tt>svn_path_canonicalize</tt>, even though this is not
 917         documented in <tt>subversion/include/svn_opt.h</tt>.  For the
 918         relative externals support, uncanonicalized paths need to be
 919         returned, otherwise scheme relative URLs,
 920         i.e. <tt>//example.com/some/path</tt> would be canonicalized
 921         to server root relative URLs <tt>/example.com/some/path</tt>.
 922         Users of this function now must ensure that they canonicalize
 923         the result of this function if they pass it to any other
 924         Subversion functions that expect a canonicalized path or URL.
 925       </li>
 926     </ul>
 927   </li>
 928
 929   <li>XXX: Enumerate specific new API additions (e.g. merge info
 930     retrieval?)</li>
 931
 932   <li>APIs backing the new <a href="#cmdline">Command-line client
 933     improvements</a> section have been added.</li>
 934
 935   <li>Many APIs have been revised to newer versions.</li>
 936
 937   <li>Most APIs which formerly took a <tt>recurse</tt> parameter have been
 938     updated to accept a <tt>depth</tt> parameter, to be used with the new
 939     <a href="#sparse-checkouts">sparse checkouts</a> feature.</li>
 940
 941   <li>Language bindings expanded and improved.</li>
 942 </ul>
 943
 944 </div>  <!-- apis -->
 945
 946 <div class="h3" id="dav-modules" title="dav-modules">
 947 <h3>Easier to try out experimental <tt>ra_serf</tt> DAV access module
 948 (<em>client</em>)</h3>
 949
 950 <p>Subversion 1.4 introduced the experimental <tt>ra_serf</tt>
 951 repository access module for accessing HTTP[S] DAV Subversion servers.
 952 This uses the <a href="http://code.google.com/p/serf/">serf</a>
 953 library instead of the Neon library which the original DAV support
 954 uses.  serf supports pipelined requests which may lead to better
 955 performance.  However, Subversion 1.4 required you to choose which
 956 module to use for accessing DAV servers at build time, which made it
 957 difficult to find out which module performs better for your usage
 958 patterns.</p>
 959
 960 <p>Subversion 1.5 allows you to build both modules at the same time;
 961 you can choose which library to use on a global or host-by-host basis
 962 by setting the <tt>http-library</tt> variable in your run-time server
 963 configuration file (<tt>~/.subversion/servers</tt>).  In recognition
 964 of the fact that both libraries are DAV clients, we have
 965 renamed <tt>ra_dav</tt> to <tt>ra_neon</tt>.</p>
 966
 967 </div>  <!-- dav-modules -->
 968
 969 <div class="h3" id="bug-fixes" title="bug-fixes">
 970 <h3>Other bug fixes (<em>client and server</em>)</h3>
 971
 972 <p>The usual slew of heretofore-unreleased bug fixes, more than XXX
 973 overall. See the
 974 <a href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a>
 975 file for full details.</p>
 976
 977 </div>  <!-- bug-fixes -->
 978
 979 </div>  <!-- enhancements -->
 980
 981 <div class="h2" id="svn-1.3-deprecation" title="svn-1.3-deprecation">
 982 <h2>Subversion 1.3.x series no longer supported</h2>
 983
 984 <p>The Subversion 1.3.x line is no longer supported.  This doesn't
 985 mean that your 1.3 installation is doomed; if it works well and is all
 986 you need, that's fine.  "No longer supported" just means we've stopped
 987 accepting bug reports against 1.3.x versions, and will not make any
 988 more 1.3.x bugfix releases, except perhaps for absolutely critical
 989 security or data-loss bugs.</p>
 990
 991 </div>  <!-- svn-1.3-deprecation -->
 992
 993 </div>  <!-- app -->
 994 </body>
 995 </html>