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><a href="#merge-tracking"
  32       >Merge tracking (foundational)</a></li>
  33   <li><a href="#sparse-checkouts"
  34       >Sparse checkouts (via new <tt>--depth</tt> option)</a></li>
  35   <li><a href="#interactive-conflict-resolution"
  36       >Interactive conflict resolution</a></li>
  37   <li><a href="#changelists"
  38       >Changelist support</a></li>
  39   <li><a href="#externals"
  40       >Relative URLs, peg revisions in <tt>svn:externals</tt></a></li>
  41   <li><a href="#cyrus-sasl"
  42       >Cyrus SASL support for ra_svn and <tt>svnserve</tt></a></li>
  43   <li><a href="#fsfs-sharding"
  44       >Improved support for large deployments on FSFS, via sharding</a></li>
  45   <li><a href="#fsfs-isolate-immutable"
  46       >Improved FSFS optimizability, via immutable file isolation</a></li>
  47   <li><a href="#webdav-proxy"
  48       >WebDAV transparent write-through proxy</a></li>
  49   <li><a href="#copy-move-improvements"
  50       >Improvements to <tt>copy</tt> and <tt>move</tt></a></li>
  51   <li><a href="#cancellation-improvements"
  52       >Speed improvements, cancellation response improvements</a></li>
  53   <li><a href="#dav-modules"
  54       >Easier to try experimental <tt>ra_serf</tt> DAV access module</a></li>
  55   <li><a href="#apis"
  56       >API changes, improvements, and much language bindings work</a></li>
  57   <li><a href="#bug-fixes"
  58       >More than 150 new bug fixes, enhancements</a></li>
  59 </ul>
  60
  61 <p>Subversion 1.5 is a superset of all previous Subversion releases,
  62 and is considered the current "best" release.  Any feature or bugfix
  63 in 1.0.x through 1.4.x is also in 1.5, but 1.5 contains features and
  64 bugfixes not present in any earlier release.  The new features will
  65 eventually be documented in a 1.5 version of the free Subversion book,
  66 see <a href="http://svnbook.red-bean.com" >svnbook.red-bean.com</a>.</p>
  67
  68 </div>  <!-- news -->
  69
  70 <div class="h2" id="compatibility" title="compatibility">
  71 <h2>Compatibility Concerns</h2>
  72
  73 <p>Older clients and servers interoperate transparently with 1.5
  74 servers and clients.  However, some of the new 1.5 features (e.g., <a
  75 href="#merge-tracking" >merge tracking</a>) may not be available
  76 unless both client and server are the latest version .  There are also
  77 cases (e.g., <a href="#sparse-checkouts">sparse checkouts</a>) where a
  78 new feature will work but will run less efficiently if the client is
  79 new and the server old.</p>
  80
  81 <p>There is <strong>no need</strong> to dump and reload your
  82 repositories.  Subversion 1.5 can read repositories created by earlier
  83 versions.  To upgrade an existing installation, just install the
  84 newest libraries and binaries on top of the older ones.</p>
  85
  86 <p>Subversion 1.5 maintains API/ABI compatibility with earlier
  87 releases, by only adding new functions, never removing old ones.  A
  88 program written to the 1.0, 1.1, 1.2, 1.3, or 1.4 API can both compile
  89 and run using 1.5 libraries.  However, a program written for 1.5
  90 cannot necessarily compile or run against older libraries.</p>
  91
  92 <div class="h3" id="wc-and-repos-format-change"
  93              title="wc-and-repos-format-change">
  94 <h3>Working Copy and Repository Format Changes</h3>
  95
  96 <p>The working copy format has been upgraded.  This means that 1.4 and
  97 older Subversion clients will <em>not</em> be able to work with
  98 working copies produced by Subversion 1.5.  Working copies are <a
  99 href="#wc-upgrades" >upgraded automatically</a>.</p>
 100
 101 <p>Similarly, the repository format has changed, meaning that 1.4 and
 102 older versions of Subversion tools that normally access a repository
 103 directly (e.g. <tt>svnserve</tt>, <tt>mod_dav_svn</tt>,
 104 <tt>svnadmin</tt>) won't be able to read a repository created by
 105 Subversion 1.5.  But, repositories are <a href="#repos-upgrades"
 106 ><strong>not</strong> upgraded automatically</a>.</p>
 107
 108 <div class="h4" id="wc-upgrades" title="wc-upgrades">
 109 <h4>Working Copy Upgrades</h4>
 110
 111 <p><strong>WARNING:</strong> if a Subversion 1.5 client encounters a
 112 pre-1.5 working copy, it will <em>automatically</em> upgrade the
 113 working copy format as soon as it touches it, making it unreadable by
 114 older Subversion clients.  If you are using several versions of
 115 Subversion on your machine, be careful about which version you use in
 116 which working copy, to avoid accidentally upgrading a working copy.
 117 (But note that this "auto upgrade" behavior does <em>not</em> occur
 118 with the <a href="#repos-upgrades" >repositories</a>, only working
 119 copies.)</p>
 120
 121 <p>If you accidentally upgrade a 1.4 working copy to 1.5, and wish to
 122 downgrade back to 1.4, use the <a
 123 href="http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py"
 124 ><tt>change-svn-wc-format.py</tt></a> script.  See <a
 125 href="http://subversion.tigris.org/faq.html#working-copy-format-change"
 126 >this FAQ entry</a> for details, and run the script with the
 127 <code>--help</code> option for usage instructions.</p>
 128
 129 </div>  <!-- wc-upgrades -->
 130
 131 <div class="h4" id="repos-upgrades" title="repos-upgrades">
 132 <h4>Repository Upgrades</h4>
 133
 134 <p>The Subversion 1.5 server works with 1.4 and older repositories,
 135 and it will <em>not</em> upgrade such repositories to 1.5 unless
 136 specifically requested to via the
 137 <strong><code>svnadmin&nbsp;upgrade</code></strong> command.  This means
 138 that some of the new 1.5 features will not become available simply by
 139 upgrading your server: you will also have to upgrade your
 140 repositories.  (We decided not to auto-upgrade repositories because we
 141 didn't want 1.5 to silently make repositories unusable by
 142 1.4&nbsp;&mdash;&nbsp;that step should be a conscious decision on the
 143 part of the repository admin.)</p>
 144
 145 <p>After running <strong><code>svnadmin&nbsp;upgrade</code></strong>,
 146 you may wish to also run the <a
 147 href="http://svn.collab.net/repos/svn/trunk/tools/server-side/svn-populate-node-origins-index.c"
 148 >svn-populate-node-origins-index</a> program on the repository.
 149 Subversion 1.5 maintains a node-origins index for each repository, and
 150 builds the index lazily as the information is needed.  But for old
 151 repositories with lots of revisions, it's better to create the index
 152 in one step, using the aforementioned tool, than to have live queries
 153 be slower until the index has built itself.  See <a
 154 href="http://subversion.tigris.org/issues/show_bug.cgi?id=3024" >issue
 155 #3024</a> for details.</p>
 156
 157 </div>  <!-- repos-upgrades -->
 158
 159 </div>  <!-- wc-and-repos-format-change -->
 160
 161 <div class="h3" id="output-changes" title="output-changes">
 162 <h3>Command Line Output Changes</h3>
 163
 164 <p>Although we try hard to keep output from the command line programs
 165 compatible between releases, new information sometimes has to be
 166 added.  This can break scripts that rely on the exact format of the
 167 output.  1.5 contains the following output changes:</p>
 168
 169 <p>XXX: Enumerate changes to output (e.g. for changelists).</p>
 170
 171 <ul>
 172   <li><p>Conflict markers in files now match the file's defined
 173     eol-style.</p></li>
 174 </ul>
 175
 176 </div>  <!-- output-changes -->
 177
 178 <div class="h3" id="sasl-compatibility" title="sasl-compatibility">
 179 <h3>SASL and <code>svn://</code> compatibility</h3>
 180
 181 <p>All 1.x clients, with or without Cyrus SASL support, will be able to
 182 authenticate against all 1.x servers that do not have Cyrus SASL enabled.
 183 Note that the <tt>CRAM-MD5</tt> and <tt>ANONYMOUS</tt> mechanisms are
 184 built into Subversion, so you'll be able to use them even if the
 185 corresponding Cyrus SASL plugins are missing.</p>
 186
 187 <p>1.x clients without Cyrus SASL support will be able to authenticate
 188 against 1.5+ servers with SASL enabled, provided the server allows the
 189 <tt>CRAM-MD5</tt> and/or <tt>ANONYMOUS</tt> mechanisms.</p>
 190
 191 <p>1.5+ clients with Cyrus SASL support will be able to authenticate against
 192 1.5+ servers with SASL enabled, provided at least one of the mechanisms
 193 supported by the server is also supported by the client.</p>
 194
 195 <p>See <a href="#cyrus-sasl" >this section</a> for more information on
 196 using Cyrus SASL with Subversion.</p>
 197
 198 </div>  <!-- sasl-compatibility -->
 199
 200 </div>  <!-- compatibility -->
 201
 202 <div class="h2" id="new-features" title="new-features">
 203 <h2>New Features</h2>
 204
 205 <div class="h3" id="merge-tracking" title="merge-tracking">
 206 <h3>Merge tracking (foundational) (<em>client and server</em>)</h3>
 207
 208 <p><em>Merge tracking</em> means Subversion keeps track of what
 209 changes have been merged where.  This reduces the overhead involved in
 210 maintaining branches, and gives users a way to inquire what changes
 211 are merged&nbsp;&mdash;&nbsp;or are available to be
 212 merged&nbsp;&mdash;&nbsp;on different lines of development.</p>
 213
 214 <p>The merge tracking support in Subversion 1.5 is "foundational": the
 215 most important parts are implemented, but there are still some parts
 216 of our <a href="http://subversion.tigris.org/merge-tracking/"
 217 >original spec</a> that remain to be done (in particular, proper
 218 support for <a
 219 href="http://subversion.tigris.org/issues/show_bug.cgi?id=2897"
 220 >reflective merges</a>, better <a
 221 href="http://subversion.tigris.org/issues/show_bug.cgi?id=3126"
 222 >change-availability reporting</a>, and better <a
 223 href="http://subversion.tigris.org/issues/show_bug.cgi?id=3128" >
 224 tracking of renamed files</a>).  As there were many major features
 225 waiting to ship in 1.5, we didn't want to delay their release by rigid
 226 adherence to one feature's specifications.  Look for further merge
 227 tracking improvements in Subversion 1.6 and afterwards.</p>
 228
 229 <div class="h4" id="mt-overview" title="mt-overview">
 230 <h4>Overview</h4>
 231
 232 <p>Subversion's merge tracking is designed to:</p>
 233
 234 <ul>
 235 <li>Reduce the bookkeeping overhead for branch maintenance</li>
 236 <li>Avoid common cases of the "repeated merge" problem</li>
 237 <li>Allow for cherry-picking of changes</li>
 238 </ul>
 239
 240 <p>Each changeset is identified by its revision number, and merged
 241 changesets are recorded in the new
 242 <strong><code>svn:mergeinfo</code></strong> property (known colloquially
 243 as "mergeinfo") set on the destination of the merge.  Subversion keeps
 244 mergeinfo up-to-date automatically, but there is also a way to <a
 245 href="#mt-record-only" >record/unrecord merges manually</a>, since
 246 there will always be cases where a human knows something that
 247 Subversion doesn't.</p>
 248
 249 </div>  <!-- mt-overview -->
 250
 251 <div class="h4" id="mt-ui" title="mt-ui">
 252 <h4>User interface</h4>
 253
 254 <p>Merging changes from (say) trunk to a branch no longer requires
 255 that you specify the revision range.  Instead, each time you want to
 256 sync up with trunk, you can just do:</p>
 257
 258 <pre>   $ cd BRANCH_WORKING_COPY
 259    $ svn merge URL_TO_TRUNK</pre>
 260
 261 <p>Subversion will figure out what changes from URL_TO_TRUNK have not
 262 yet been merged and pull in just those changes.  When it's time to
 263 merge the branch back to trunk, do this:</p>
 264
 265 <pre>   $ cd TRUNK_WORKING_COPY
 266    $ svn merge --reintegrate URL_TO_BRANCH</pre>
 267
 268 <p>Below is a more formal description of all the
 269 merge-tracking-related interface changes.</p>
 270
 271 <p>The <strong><code>svn&nbsp;merge</code></strong> command takes two new
 272 options: <strong><code>--record-only</code></strong> and
 273 <strong><code>--reintegrate</code></strong>.</p>
 274
 275 <div id="mt-record-only" title="mt-record-only">
 276 <p>The --record-only option works with -r and does exactly what you
 277 think it does: it marks a revision as merged (or unmerged, if using
 278 the "-" revision number negation syntax), without actually changing
 279 anything besides the mergeinfo.  For example, this would be useful
 280 when someone has hand-edited a file in such a way as to effectively
 281 incorporate a change that was already made somewhere else.  Rather
 282 than have the original change be ported over in the next
 283 synchronization merge, thus risking textual conflicts wherever the two
 284 versions trivially differ, you can just record the change as already
 285 merged.  (See <a
 286 href="http://subversion.tigris.org/merge-tracking/requirements.html#manual-merge"
 287 >the merge-tracking requirements</a>, and <a
 288 href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges"
 289 >Blocking Changes</a> in the Subversion book, for more details.)</p>
 290 </div>  <!-- mt-record-only -->
 291
 292 <p>The --reintegrate option is used when merging a branch back to
 293 trunk; it checks for some common safeguard conditions and then does
 294 the merge in a fast and efficient way.  See <a
 295 href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync"
 296 >Keeping a branch in sync</a> in the Subversion book for more.</p>
 297
 298 <p>The new <strong><code>svn&nbsp;mergeinfo</code></strong> command can
 299 show which changesets a directory has absorbed and which changesets
 300 it's still eligible to receive.  See <a
 301 href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.mergeinfo"
 302 >Mergeinfo and Previews</a> in the Subversion book for more information.</p>
 303
 304 <p>The <strong><code>svn&nbsp;log</code></strong> and
 305 <strong><code>svn&nbsp;blame</code></strong> commands take a new
 306 <strong><code>-g</code></strong>
 307 (<strong><code>--use-merge-history</code></strong>) option, which tells
 308 them to take mergeinfo into account.  Without this option, they won't.</p>
 309
 310 <p>The reason for the -g option is that it is sometimes useful to
 311 ignore merge history.  In blame output you sometimes want to see the
 312 person B who merged a change, though other times you want to see the
 313 person A who originally wrote the change that B later merged; use -g
 314 to get the latter information.  In log output, you sometimes want to
 315 see exactly the revisions that were committed on a given line of
 316 development, though other times you want to see, as part of the same
 317 output, the original changes that were later ported as merge
 318 revisions; again, -g includes the latter information (tagged with
 319 lines that say "<tt>Merged via: </tt>" followed by the revision number
 320 in which the merge took place).  See <a
 321 href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.logblame"
 322 >Merge-Sensitive Logs and Annotations</a> in the Subversion book for
 323 more details.</p>
 324
 325 </div>  <!-- mt-ui -->
 326
 327 <div class="h4" id="mt-compatibility" title="mt-compatibility">
 328 <h4>Merge tracking and compatibility</h4>
 329
 330 <p>As described earlier, merge-tracking is not supported unless you <a
 331 href="#repos-upgrades" >upgrade the repository</a> as well as the
 332 server.</p>
 333
 334 <p>If you were using the <a
 335 href="https://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/"
 336 >svnmerge</a> wrapper program to do merging, and now want to switch to
 337 using Subversion 1.5's native merge-tracking, then you should use the
 338 <a
 339 href="https://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/svnmerge-migrate-history.py"
 340 >svnmerge-migrate-history.py</a> script to convert svnmerge's custom
 341 properties to the <tt>svn:mergeinfo</tt> properties that Subversion
 342 itself now uses.</p>
 343
 344 </div>  <!-- mt-compatibility -->
 345
 346 <div class="h4" id="mt-further-reading" title="mt-further-reading">
 347 <h4>Further reading</h4>
 348
 349 <p>For more on merge-tracking in Subversion 1.5, see:</p>
 350
 351 <ul>
 352 <li><a href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html"
 353     >Chapter 4: Branching and Merging</a> in the Subversion book
 354 </li>
 355 <li><a href="http://subversion.tigris.org/merge-tracking/" >The merge
 356     tracking design documents</a>
 357     (requirements, use cases, functional spec, design)
 358 </li>
 359 </ul>
 360
 361 </div> <!-- mt-further-reading -->
 362
 363 </div> <!-- merge-tracking -->
 364
 365 <div class="h3" id="sparse-checkouts" title="sparse-checkouts">
 366 <h3>Sparse checkouts  (<em>client and server</em>)</h3>
 367
 368 <p>Many users have very large trees of which they only want to
 369 checkout certain parts.  In previous versions of Subversion,
 370 <code>checkout -N</code> was not really up to this task.  Subversion
 371 1.5 introduces the <strong><code>--depth</code></strong> option to the
 372 <strong><code>checkout</code></strong>,
 373 <strong><code>switch</code></strong>, and
 374 <strong><code>update</code></strong> subcommands.  This option
 375 replaces <code>-N</code>, and allows users to construct working
 376 copies containing just what's needed, leaving out everything else.</p>
 377
 378 <div class="h4" id="sc-depth" title="sc-depth">
 379 <h4>Depth overview</h4>
 380 <p>Each directory now understands the notion of <em>depth</em>, which has
 381 four possible values: <tt>empty</tt>, <tt>files</tt>, <tt>immediates</tt>,
 382 <tt>infinity</tt>.  The values are defined as follows:</p>
 383
 384 <table border="1">
 385 <tr>
 386   <td><tt>empty</tt></td>
 387   <td>Updates will not pull in any files or subdirectories not already
 388     present.</td>
 389 </tr>
 390 <tr>
 391   <td><tt>files</tt></td>
 392   <td>Updates will pull in any files not already present, but not
 393     subdirectories.</td>
 394 </tr>
 395 <tr>
 396   <td><tt>immediates</tt></td>
 397   <td>Updates will pull in any files or subdirectories not already present;
 398     those subdirectories' will have depth-empty.</td>
 399 </tr>
 400 <tr>
 401   <td><tt>infinity</tt></td>
 402   <td>Updates will pull in any files or subdirectories not already present;
 403     those subdirectories' will have depth-infinity.  Equivalent to today's
 404     default update behavior.</td>
 405 </tr>
 406 </table>
 407
 408 <p>The <code>--depth</code> option sets depth values as it updates the working
 409 copy, tweaking new subdirectories' depth values as described above.</p>
 410
 411 </div>  <!-- sc-depth -->
 412
 413 <div class="h4" id="sc-ui" title="sc-ui">
 414 <h4>User Interface</h4>
 415 <p>Affected commands:</p>
 416 <ul>
 417   <li><code>checkout</code></li>
 418   <li><code>switch</code></li>
 419   <li><code>update</code></li>
 420   <li><code>status</code></li>
 421   <li><code>info</code></li>
 422 </ul>
 423
 424 <p>The <code>-N</code> option becomes a synonym for <code>--depth=files</code>
 425 for these commands.  This changes the existing <code>-N</code> behavior for
 426 these commands, but in a trivial way (see below).</p>
 427
 428 <p><code>checkout</code> without <code>--depth</code> or
 429 <code>-N</code> behaves the same as it does today.
 430 <code>switch</code> and <code>update</code> without
 431 <code>--depth</code> or <code>-N</code> behave the same way as today
 432 if and only if the working copy is fully depth-infinity.
 433 <code>switch</code> and <code>update</code> without
 434 <code>--depth</code> or <code>-N</code> will <em>not</em> change depth
 435 values (exception: a missing directory specified on the command line
 436 will be pulled in).</p>
 437
 438 <p>Thus, <code>checkout</code> is identical to <code>checkout
 439 --depth=infinity</code>, but <code>switch</code> and <code>update</code> are
 440 not the same as <code>switch --depth=infinity</code> and <code>update
 441 --depth=infinity</code>.  The former update entries according to existing depth
 442 values, while the latter pull in everything.</p>
 443
 444 <p>To get started, run <code>checkout</code> with
 445 <code>--depth=empty</code> or <code>--depth=files</code>.  If
 446 additional files or directories are desired, pull them in with
 447 <code>update</code> commands using appropriate <code>--depth</code>
 448 options.  The <code>svn status</code> command should list the ambient
 449 depths of directories, in addition to whatever other statuses are
 450 listed.  The <code>svn info</code> command also lists ambient depth,
 451 when invoked on a directory whose depth is not the default
 452 (depth-infinity)</p>
 453
 454 <p><strong>Note:</strong> There is currently no <em>deselection</em>
 455 interface for sparse checkouts&nbsp;&mdash;&nbsp;that is, there is no
 456 command to unselect or "fold up" a subdirectory after you've brought
 457 it into a sparse working copy (although there are some fairly easy
 458 workarounds to achieve the same effect).  See <a
 459 href="http://subversion.tigris.org/issues/show_bug.cgi?id=2843" >issue
 460 #2843</a> for details.</p>
 461
 462 </div>  <!-- sc-ui -->
 463
 464 <div class="h4" id="sc-compat" title="sc-compat">
 465 <h4>Compatibility with older servers</h4>
 466
 467 <p>The new <tt>--depth</tt> feature naturally requires the client to
 468 be 1.5+, and will work most efficiently if the server is also 1.5+.
 469 However, the client will still behave correctly if the server is 1.4.x
 470 or lower; things will just be less efficient.</p>
 471
 472 <p>This is because older servers do not
 473 understand&nbsp;&mdash;&nbsp;and therefore
 474 ignore&nbsp;&mdash;&nbsp;what the client tells them about "depth".  So
 475 when a client requests a depth shallower than depth-infinity, older
 476 servers will send back more data than the client wants.  However, a
 477 1.5+ client will know it's talking to an older server and filter out
 478 this extra data.  Thus, operations may take a while, because the
 479 server sends a lot of data over the network that the client then
 480 ignores, but the final result on the client side will be the same.
 481 (Note that older servers understand a <tt>recurse</tt> flag in the
 482 network protocols, and 1.5+ clients send that flag based on the depth;
 483 this alleviates some of the extra network traffic penalty.)</p>
 484
 485 </div>  <!-- sc-compat-dac -->
 486
 487 </div>  <!-- sc-compat -->
 488
 489 <div class="h4" id="sc-further-reading" title="sc-further-reading">
 490 <h4>Further reading</h4>
 491
 492 <ul>
 493 <li>The <a
 494     href="http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html"
 495     >Sparse Directories</a> section in the Subversion book.
 496 </li>
 497 <li>The <a
 498     href="http://svn.collab.net/repos/svn/trunk/notes/sparse-directories.txt"
 499     >design/implementation document</a> in the repository.</li>
 500 </ul>
 501
 502 </div> <!-- sc-further-reading -->
 503
 504 </div> <!-- sparse-checkouts -->
 505
 506 <div class="h3" id="interactive-conflict-resolution"
 507              title="interactive-conflict-resolution">
 508 <h3>Interactive Conflict Resolution (<em>client</em>)</h3>
 509
 510 <p>Conflict resolution is now done interactively by the command-line
 511 client for the
 512 <code>update</code>/<code>switch</code>/<code>merge</code>
 513 subcommands, and the client library offers a callback function so
 514 other clients can do similarly.</p>
 515
 516 <p>Here's an example using the command-line client:</p>
 517
 518 <pre>
 519    $ svn up
 520    U    contrib/client-side/svnmerge/svnmerge_test.py
 521    Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
 522    Select: (p) postpone, (df) diff-full, (e) edit,
 523            (s) show all options: s
 524      (p)  postpone    - mark the conflict to be resolved later
 525      (df) diff-full   - show all changes made to merged file
 526      (e)  edit        - change merged file in an editor
 527      (r)  resolved    - accept merged version of file
 528      (mf) mine-full   - accept my version of entire file (ignore their changes)
 529      (tf) theirs-full - accept their version of entire file (lose my changes)
 530      (l)  launch      - launch external tool to resolve conflict
 531      (s)  show all    - show this list
 532
 533    Select: (p) postpone, (df) diff-full, (e) edit,
 534            (s) show all options: tf
 535    G    contrib/client-side/svnmerge/svnmerge.py
 536    Updated to revision 25685.
 537    $
 538 </pre>
 539
 540 <p>This feature can be selectively disabled by using the --non-interactive
 541 option, or disabled permanently by setting '[miscellany] interactive-conflicts
 542  = no' in your run-time config file.</p>
 543
 544 <p>The API for interactive conflict resolution is exposed via a
 545 callback function and the following new data types:</p>
 546
 547 <ul>
 548   <li><code>svn_wc_conflict_resolver_func_t</code>, the callback API
 549     itself</li>
 550   <li><code>svn_wc_conflict_description_t</code>, a description of the
 551     conflict passed to the callback</li>
 552   <li><code>svn_wc_conflict_action_t</code>, the part of the conflict
 553     description indicating what the merge was trying to do</li>
 554   <li><code>svn_wc_conflict_reason_t</code>, the part of the conflict
 555     description indicating the type of conflict</li>
 556   <li><code>svn_wc_conflict_result_t</code>, returned by the callback
 557     as the result of any conflict resolution attempt</li>
 558   <li><code>svn_wc_conflict_choice_t</code>, an enum indicating what
 559     course of action the user chose</li>
 560 </ul>
 561
 562 <p>Clients provide their callback function to Subversion's libraries
 563 by setting it on the (new) <code>conflict_func</code> field of their
 564 <code>svn_client_ctx_t</code>, and may provide additional state to the
 565 callback via the corresponding <code>conflict_baton</code> field.</p>
 566
 567 </div>  <!-- interactive-conflict-resolution -->
 568
 569 <div class="h3" id="changelists" title="changelists"> <h3>Changelist
 570 support (<em>client</em>)</h3> <p>The Subversion client now contains
 571 the notion of a <em>changelist</em>: a group of files which are
 572 associated with a chosen name.  This becomes especially useful when
 573 working on several different set of files within the same working
 574 copy.  Instead of having to remember each file in each set, Subversion
 575 1.5 will allow you to associate a changelist with each set of files.
 576 Most commands which take a set of files as targets will now also
 577 accept the <strong><code>--changelist</code></strong> option, which
 578 filters those targets based upon the members of the changelist.
 579 Changelist membership can be edited using the new
 580 <strong><code>changelist</code></strong> subcommand.</p>
 581
 582 <p>Changelists are handled entirely by the client.  They are never sent
 583 to the server, and aren't visible to other users of the same repository.
 584 Also, the <code>--changelist</code> option is never additive; if a file
 585 wouldn't have been included in the list of targets without
 586 <code>--changelist</code>, it will not be added to it, regardless of membership
 587 in the changelist.  Currently, a file may only be in one changelist at a
 588 time, and directories can not be members of a changelist.</p>
 589
 590 <p>The <code>--changelist</code> option is supported by the following
 591 subcommands:</p>
 592 <ul>
 593   <li><code>changelist</code></li>
 594   <li><code>commit</code></li>
 595   <li><code>diff</code> (only wc-wc and wc-repos cases)</li>
 596   <li><code>info</code></li>
 597   <li><code>propget</code></li>
 598   <li><code>proplist</code></li>
 599   <li><code>propset</code></li>
 600   <li><code>propdel</code></li>
 601   <li><code>revert</code></li>
 602   <li><code>status</code></li>
 603   <li><code>update</code></li>
 604 </ul>
 605
 606 <div class="h4" id="cl-further-reading" title="cl-further-reading">
 607 <h4>Further reading</h4>
 608
 609 <ul>
 610 <li>The <a
 611     href="http://svnbook.red-bean.com/nightly/en/svn.advanced.changelists.html"
 612     >Changelists</a> section in the Subversion book.
 613 </li>
 614 <li>The <a
 615     href="http://svn.collab.net/repos/svn/trunk/notes/changelist-design.txt"
 616     >design/implementation document</a> in the repository.</li>
 617 </ul>
 618
 619 </div>  <!-- cl-further-reading -->
 620
 621 </div>  <!-- changelists -->
 622
 623 <div class="h3" id="externals" title="externals">
 624 <h3>Relative URLs, peg revisions in <tt>svn:externals</tt>
 625     (<em>client</em>)</h3>
 626
 627 <p>Two additions to the <tt>svn:externals</tt> feature</p>
 628
 629 <div class="h4" id="externals-peg-revs" title="externals-peg-revs">
 630 <h4>Peg revision syntax for URLs</h4>
 631
 632 <p><em>Compatibility and the new syntax:</em> For compatibility
 633 reasons, the pre-1.5 svn:externals syntax continues to not understand
 634 peg revisions.  A new format has been introduced to allow peg
 635 revisions in URLs.</p>
 636
 637 <p>The old format of</p>
 638 <pre>
 639    foo             http://example.com/repos/zig
 640    foo/bar -r 1234 http://example.com/repos/zag
 641 </pre>
 642
 643 <p>does not support peg revisions, and the following externals will
 644 not work (unless there are directories named <tt>zig@HEAD</tt> and
 645 <tt>zag@HEAD</tt>):</p>
 646
 647 <pre>
 648    foo             http://example.com/repos/zig@HEAD
 649    foo/bar -r 1234 http://example.com/repos/zag@HEAD
 650 </pre>
 651
 652 <p>The new format moves the URL first followed by the directory the
 653 external is checked out or exported into; if there is an operative
 654 (-r) revision, it precedes the URL.  Here are four externals lines:</p>
 655
 656 <pre>
 657    http://example.com/repos/zig foo1
 658    -r 1234 http://example.com/repos/zag foo/bar1
 659    http://example.com/repos/zig@HEAD foo2
 660    -r 1234 http://example.com/repos/zag@HEAD foo/bar2
 661 </pre>
 662
 663 <p>In other words, both operative ("-r") and peg ("@") revisions are
 664 allowed, but neither is required.</p>
 665
 666 </div>  <!-- externals-peg-revisions -->
 667
 668 <div class="h4" id="externals-relative-urls" title="externals-relative-urls">
 669 <h4>Support for relative URLs</h4>
 670
 671 <p>Prior to Subversion 1.5, the URLs in an <tt>svn:externals</tt>
 672 specification must be absolute.  Now they can be relative.  Four
 673 different relative externals specifications are supported.  (In the
 674 following examples, assume we have two repositories: one at
 675 <tt>http://example.com/svn/repos-1</tt> and another at
 676 <tt>http://example.com/svn/repos-2</tt>.  We have a checkout of
 677 <tt>http://example.com/svn/repos-1/project1/trunk</tt> and the
 678 <tt>svn:externals</tt> property is set on <tt>trunk</tt>.)</p>
 679
 680 <dl><dt><strong>../</strong></dt>
 681 <dd><p>Relative to the directory with the <tt>svn:externals</tt>
 682 property.  These URLs always begin with the string <tt>../</tt>, for
 683 example:</p>
 684 <pre>
 685    ../../project2/trunk common/project2/trunk
 686 </pre>
 687
 688 <p>This will extract
 689 <tt>http://example.com/svn/repos-1/project2/trunk</tt> into
 690 <tt>common/project2/trunk</tt>.  The external's URL is relative to the
 691 URL of the directory with the <tt>svn:externals</tt> property, not the
 692 directory where the external is written to disk.</p></dd>
 693
 694 <dt><strong>^/</strong></dt>
 695
 696 <dd><p>Relative to the repository root.</p>
 697
 698 <pre>
 699    ^/project2/trunk common/project2/trunk
 700 </pre>
 701
 702 <p>This will extract
 703 <tt>http://example.com/svn/repos-1/project2/trunk</tt> into
 704 <tt>common/project2/trunk</tt>.</p>
 705
 706 <p>You can also refer to other repositories easily using repository
 707 root relative URLs:</p>
 708
 709 <pre>
 710    ^/../repos-2/foo/trunk common/foo/trunk
 711 </pre>
 712
 713 <p>This will extract <tt>http://example.com/svn/repos-2/foo/trunk</tt>
 714 into <tt>common/foo/trunk</tt>.</p>
 715 </dd>
 716
 717 <dt><strong>//</strong></dt>
 718
 719 <dd><p>Relative to the scheme.  This copies the scheme of the checkout
 720 or export URL into the URL in <tt>svn:externals</tt>.  It is useful
 721 when the same hostname must the accessed with different schemes
 722 depending upon network location; i.e. clients in the intranet use
 723 <tt>http://</tt> while external clients use <tt>svn+ssh://</tt>.</p>
 724
 725 <pre>
 726    //example.com/svn/repos-1/project2/trunk common/project2/trunk
 727 </pre>
 728
 729 <p>This will extract
 730 <tt>http://example.com/svn/repos-1/project2/trunk</tt> into
 731 <tt>common/project2/trunk</tt>.  If the working copy was checked out
 732 from <tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt> then
 733 this URL would be
 734 <tt>http://example.com/svn/repos-1/project1/trunk</tt>.</p>
 735 </dd>
 736
 737 <dt><strong>/</strong></dt>
 738
 739 <dd><p>Server root relative URLs.  This copies the scheme and hostname
 740 from the checkout or export URL into the <tt>svn:externals</tt>
 741 URL.</p>
 742
 743 <pre>
 744    /svn/repos-1/project2/trunk common/project2/trunk
 745 </pre>
 746
 747 <p>This will extract
 748 <tt>http://example.com/svn/repos-1/project2/trunk</tt> into
 749 <tt>common/project2/trunk</tt>.  If the working copy was checked out
 750 from <tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt> then
 751 this URL would be
 752 <tt>http://example.com/svn/repos-1/project1/trunk</tt>.</p>
 753 </dd>
 754
 755 </dl>
 756
 757 <p>Relative URLs are still supported in the old <tt>svn:externals</tt>
 758 format (that does not support peg revisions).</p>
 759
 760 <p>When Subversion sees an <tt>svn:externals</tt> without an absolute
 761 URL, it takes the first argument as a relative URL and the second as
 762 the target directory.</p>
 763
 764 </div>  <!-- externals-relative-urls -->
 765
 766 <div class="h4" id="externals-further-reading"
 767              title="externals-further-reading">
 768 <h4>Further reading</h4>
 769
 770 <p>See The <a
 771 href="http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html"
 772 >svn:externals</a> section of the Subversion Book.  (XXX TODO: which
 773 needs to be updated to cover the new features!)</p>
 774
 775 </div>  <!-- externals-further-reading -->
 776
 777 </div>  <!-- externals -->
 778
 779 <div class="h3" id="cyrus-sasl" title="cyrus-sasl">
 780 <h3>Cyrus SASL support for ra_svn and <tt>svnserve</tt> (<em>client
 781 and server</em>)</h3>
 782
 783 <p>From <a
 784 href="http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer">
 785 Wikipedia</a>: "SASL is a framework for authentication and data security in
 786 Internet protocols.  It decouples authentication mechanisms from application
 787 protocols, in theory allowing any authentication mechanism supported by SASL to
 788 be used in any application protocol that uses SASL."</p>
 789
 790 <p>In practice, the server sends a list of authentication mechanisms that it
 791 supports.  The client then selects one of these mechanisms based on what the
 792 client supports, and informs the server of its decision.  After that, a
 793 number of messages are exchanged until either authentication succeeds or an
 794 error occurs.  In the latter case, the client is allowed to restart
 795 authentication.</p>
 796
 797 <p>The <tt>svn://</tt> protocol has always supported this type of negotiation.
 798 However, only the <tt>CRAM-MD5</tt> and <tt>ANONYMOUS</tt> mechanisms were
 799 implemented.  <a href="http://asg.web.cmu.edu/sasl/">Cyrus SASL</a> supports
 800 all these, and, in addition, provides a host of other mechanisms such as
 801 <tt>DIGEST-MD5</tt>, OTP (One-Time Passwords), GSSAPI (used for Kerberos
 802 authentication), NTLM (NT LAN Manager), SRP (Secure Remote Password), and
 803 others.  The exact list of available mechanisms depends on how SASL was
 804 compiled, as many of them either have external dependencies, or are not
 805 built by default.  Also, because each mechanism is actually a shared library
 806 that is dynamically loaded at runtime, many distributions package these
 807 mechanisms separately from the core library.</p>
 808
 809 <p>Please see the <a href="#sasl-compatibility">compatibility
 810 section</a> for information regarding using a 1.5 SASL-enabled server
 811 with pre-1.5 clients.  More information about Subversion's SASL
 812 support can be found in <a
 813 href="http://svn.collab.net/repos/svn/trunk/notes/sasl.txt"
 814 >sasl.txt</a>.</p>
 815
 816 </div> <!-- cyrus-sasl -->
 817
 818 <div class="h3" id="fsfs-sharding" title="fsfs-sharding">
 819 <h3>Improved support for large deployments on FSFS, via sharding
 820     (<em>server</em>)</h3>
 821
 822 <p>The FSFS filesystem backend stores each revision in its own file, and prior
 823 to Subversion 1.5, all of these files were stored in a common directory in
 824 the repository.  Now, <em>newly created</em> FSFS repositories will use a
 825 two-level directory tree with up to (by default) 1000 files per directory.
 826 These repositories will only be compatible with other Subversion 1.5 clients,
 827 but of course, Subversion 1.5 will be able to continue using repositories
 828 employing the older scheme without any problem.</p>
 829
 830 <p>The primary reason for the change is to allow the revision count to
 831 grow beyond the filesystem's (efficient) directory entry limit.  While
 832 modern filesystems can support millions of entries per directory, they
 833 become slower and common administrative tools (e.g. directory
 834 listings, backups) become unwieldy or fail completely.</p>
 835
 836 <p>For more information about the technical underpinnings of FSFS sharding,
 837 see this <a href="http://www.farside.org.uk/200704/tree_structured_fsfs">blog
 838 entry</a>.
 839 <!-- ### Reshard script is not quite finished and currently
 840      ### aborts if you try to run it.
 841  <a
 842  href="http://svn.collab.net/repos/svn/trunk/tools/server-side/fsfs-reshard.py"
 843  >Migration script</a> provided.
 844 -->
 845 </p>
 846
 847 <p>The shard size can by adjusted by editing the
 848 "<code>layout&nbsp;sharded</code>" line in "db/format" after
 849 <code>svnadmin&nbsp;create</code> but before populating the
 850 repository.</p>
 851
 852 </div>  <!-- fsfs-sharding -->
 853
 854 <div class="h3" id="fsfs-isolate-immutable" title="fsfs-isolate-immutable">
 855 <h3>Improved FSFS optimizability, via immutable file isolation
 856     (<em>server</em>)</h3>
 857
 858 <p>The FSFS repositories never change a revision after it is written
 859 to the disk.  Although this should allow the operating system to cache
 860 these files forever, certain filesystems (e.g. NFS) prohibit such
 861 caching by default.  Now the FSFS repository layout has been changed
 862 such that the immutable files are confined to the subdirectories
 863 "db/revs" and "db/txn-protorevs".  This allows these directories to be
 864 on a mount point where caching is enabled (on Linux look at the
 865 "nocto" option to nfs(5)).</p>
 866
 867 <p>Since commit transactions are now built up in "db/txn-protorevs"
 868 instead of "db/transactions", the latter directory no longer needs to
 869 be on the same mount point.  If the repository is stored on a slower
 870 filesystem (e.g. NFS), then commit performance can be improved by
 871 moving the transactions directory to local disk (using a symbolic
 872 link).  If you are using multiple svn servers behind a network load
 873 scaler, you must configure the load scaler to direct to the same
 874 server for the duration of the transaction.  This is typically called
 875 "client affinity".</p>
 876
 877 </div>  <!-- fsfs-isolate-immutable -->
 878
 879 <div class="h3" id="webdav-proxy" title="webdav-proxy">
 880 <h3>WebDAV transparent write-through proxy (<em>server</em>)</h3>
 881
 882 <p>Subversion 1.4 <a
 883 href="http://subversion.tigris.org/svn_1.4_releasenotes.html#svnsync">
 884 introduced <tt>svnsync</tt></a>&nbsp;&mdash;&nbsp;a tool which
 885 provided the ability to replicate repository history from one
 886 repository to another.  Though useful, <tt>svnsync</tt> could only
 887 pull revision history from a repository, not push additional commits
 888 back to the master.  Subversion 1.5 adds WebDAV proxy support to
 889 <tt>mod_dav_svn</tt>, effectively allowing bidirectional revision
 890 history replication between master servers and slave servers using
 891 <tt>mod_dav_svn</tt>.</p>
 892
 893 <p>All clients interact with a slave server, but the slave transparently
 894 passes all of the write-oriented activites to the master (rewriting the
 895 content as necessary).  The slaves are essentially read-only, but they
 896 do have a complete copy of the repository locally.  This serves to
 897 alleviate read traffic from the master server which may be desirable
 898 in certain circumstances.</p>
 899
 900 <p>This model has several advantages to using a straight HTTP DAV-aware
 901 caching proxy, in that each slave can respond to all read-only requests
 902 without ever having to relay them to the master backend.</p>
 903
 904 <div class="h4" id="webdav-proxy-requirements"
 905     title="webdav-proxy-requirements">
 906 <h4>Requirements</h4>
 907 <ul>
 908   <li>Subversion 1.5 or newer.</li>
 909   <li>Apache HTTP Server 2.2.0 or higher with mod_proxy enabled.
 910     (Several fixes to mod_proxy were committed for this patch that were not
 911     backported to the 2.0 branch of httpd.)</li>
 912 </ul>
 913
 914 </div>  <!-- webdav-proxy-requirements -->
 915
 916 <div class="h4" id="webdav-proxy-example" title="webdav-proxy-example">
 917 <h4>Example configuration</h4>
 918
 919 <p>Participants:</p>
 920 <ul>
 921   <li>Slave &rarr; <tt>slave.example.com</tt>  (there can be many!)</li>
 922   <li>Master &rarr; <tt>master.example.com</tt> (there can only be one!)</li>
 923   <li>A WebDAV client (<tt>ra_neon</tt>, <tt>ra_serf</tt>, other WebDAV
 924     clients)</li>
 925 </ul>
 926
 927 <p>Each client does:</p>
 928 <pre><code>
 929     % svn co http://slave.example.com/repos/slave/
 930     ...
 931     % svn ci
 932     % ...etc...
 933 </code></pre>
 934 <p>(The client can perform all operations as normal.)</p>
 935
 936 <p>Each slave has:</p>
 937 <pre><code>
 938     &lt;Location /repos/slave&gt;
 939       DAV svn
 940       SVNPath /my/local/copy/of/repos
 941       SVNMasterURI http://master.example.com/repos/master/
 942     &lt;/Location&gt;
 943 </code></pre>
 944
 945 <p>The master MUST have a post-commit hook that updates all of the slaves.  An
 946 example that does this using <code>svnadmin dump</code>/<code>svnadmin
 947 load</code> and ssh is provided below.  <tt>svnsync</tt> can probably do the
 948 same thing (XXX: we should probably answer this question more confidently).</p>
 949
 950 <p>Additionally, if locks are permitted on the master repository, lock databases
 951 need to kept in sync via post-lock and post-unlock hooks on the master pushing
 952 the lock state to the slaves.  (Username preservation is left as an exercise to
 953 the reader.)(XXX: Same as above.)  If the lock database is not propogated, users
 954 will not be able to accurately determine whether a lock is held - but locking
 955 will still work.</p>
 956
 957 <p>A sample synchronization script may look like this:</p>
 958 <pre><code>
 959    #!/bin/sh
 960    REPOS="$1"
 961    REV="$2"
 962    SLAVE_HOST=slave.example.com
 963    SLAVE_PATH=/my/local/copy/of/repos
 964
 965    # Ensure svnadmin is in $PATH on both this machine and the remote server!
 966    svnadmin dump --incremental -r$2 $1 &gt; /tmp/$2.dump
 967    scp /tmp/$2.dump $SLAVE_HOST:$SLAVE_PATH
 968    ssh $SLAVE_HOST "svnadmin load $SLAVE_PATH &lt; $SLAVE_PATH/$2.dump"
 969    ssh $SLAVE_HOST "rm $SLAVE_PATH/$2.dump"
 970    rm /tmp/$2.dump
 971 </code></pre>
 972
 973 </div>  <!-- webdav-proxy-example -->
 974
 975 <div class="h4" id="webdav-proxy-further-reading"
 976              title="webdav-proxy-further-reading">
 977 <h4>Further reading</h4>
 978
 979 <p>Additional information about WebDAV proxy support is available <a
 980 href="http://svn.collab.net/repos/svn/trunk/notes/webdav-proxy">in the
 981 repository</a>.</p>
 982
 983 </div>  <!-- webdav-proxy-further-reading -->
 984
 985 </div>  <!-- webdav-proxy -->
 986
 987 </div>  <!-- new-features -->
 988
 989
 990 <div class="h2" id="enhancements" title="enhancements">
 991 <h2>Enhancements and Bugfixes</h2>
 992
 993 <div class="h3" id="copy-move-improvements" title="copy-move-improvements">
 994 <h3>Copy/move-related improvements (<em>client and server</em>)</h3>
 995
 996 <p>The abilities and behavior of <code>copy</code> and
 997 <code>move</code> operations are significantly improved in 1.5+.</p>
 998
 999 <div class="h4" id="leverage-copyfrom" title="leverage-copyfrom">
1000 <h4>Improved copy-handling during updates (<em>client and server</em>)</h4>
1001
1002 <p>A common problem in older versions of Subversion was the way in
1003 which <code>svn update</code> handled incoming copies and moves.</p>
1004
1005 <p>Consider this scenario: Harry runs <code>svn move foo bar; svn
1006 commit</code>, and meanwhile Sally makes local changes to 'foo', and
1007 then runs <code>svn update</code>.  In earlier versions of Subversion,
1008 the server would send down a completely new file 'bar', and unversion
1009 the file 'foo' (if it had no uncommitted changes, Subversion would
1010 remove it entirely.)  From Sally's point of view, her changes seem to
1011 be lost; the newly added 'bar' file has the older content, and the
1012 file 'foo' has been taken out of version control.</p>
1013
1014 <p>In Subversion 1.5, the client and server both attempt to be smarter
1015 about this.  The server doesn't send a whole new file during the
1016 update, but rather instructions to copy something that likely already
1017 exists in the working copy.  So Sally's 'foo' file is copied to 'bar'
1018 (with local edits intact!).</p>
1019
1020 <p>In theory, this is the best-case scenario.  There are a few
1021 caveats: this "proper copying" of existing working-copy resources only
1022 works on files, not (yet) on directories.  Also, if an incoming
1023 move-operation deletes 'foo' before it attempts to copy it to 'bar',
1024 then the copy will fail, and the client reverts to the old behavior of
1025 fetching a pristine copy of the file from the repository.  We hope to
1026 address this in svn 1.6.</p>
1027
1028 <p>See <a
1029 href="http://subversion.tigris.org/issues/show_bug.cgi?id=503" >issue
1030 #503</a> for more.</p>
1031
1032 </div> <!-- leverage-copyfrom -->
1033
1034 <div class="h4" id="copy-peg-revs" title="copy-peg-revs">
1035 <h4>Peg revisions (<em>client</em>)</h4>
1036
1037 <p>Copy and move operations now accept sources with peg ("@")
1038 revisions.</p>
1039
1040 <p>See <a
1041 href="http://subversion.tigris.org/issues/show_bug.cgi?id=2546" >issue
1042 #2546</a> for more.</p>
1043
1044 </div>  <!-- copy-peg-revs -->
1045
1046 <div class="h4" id="multi-op-copy-move" title="multi-op-copy-move">
1047 <h4>Multiple working copy copy/move operations (<em>client</em>)</h4>
1048
1049 <p>Clients may now perform chained copy/move operations locally on a
1050 single object in a working copy:</p>
1051
1052 <pre>
1053    svn mv path1 path2
1054    svn mv path2 path3
1055 </pre>
1056
1057 <p>See <a
1058 href="http://subversion.tigris.org/issues/show_bug.cgi?id=756" >issue
1059 #756</a> for more.</p>
1060
1061 </div>  <!-- multi-op-copy-move -->
1062
1063 <div class="h4" id="multi-src-copy" title="multi-src-copy">
1064 <h4>Improved handling multiple copy/move sources (<em>client</em>)</h4>
1065
1066 <p>Clients now accept multiple sources for copy and move operations, with
1067 the ability to copy/move each of the sources to the specified directory.
1068 This mirrors the behavior of standard command-line copy and move tools,
1069 such as <code>cp</code> and <code>mv</code>.  For example:</p>
1070
1071 <pre>
1072    svn mkdir new_subdir
1073    svn mv foo.txt bar.txt baz.txt new_subdir
1074 </pre>
1075
1076 <p>In practice, this means users can take advantage of shell globbing
1077 when doing a local copy or move:</p>
1078
1079 <pre>
1080    svn cp *.c dir
1081 </pre>
1082
1083 <p>Multiple source copy/move also works for all previously defined
1084 copy/move working copy and repository combinations.</p>
1085
1086 <p>See <a
1087 href="http://subversion.tigris.org/issues/show_bug.cgi?id=747" >issue
1088 #747</a> for more.</p>
1089
1090 </div>  <!-- multi-src-copy -->
1091
1092 <div class="h4" id="cp-takes-base" title="cp-takes-base">
1093 <h4>Copy takes -rBASE (<em>client</em>)</h4>
1094
1095 <p>Copy now understands the special revision "BASE" in a working copy
1096 (as in: "<tt>-rBASE</tt>").</p>
1097
1098 <p>See <a
1099 href="http://subversion.tigris.org/issues/show_bug.cgi?id=1643" >issue
1100 #1643</a> for more.</p>
1101
1102 </div>  <!-- cp-takes-base -->
1103
1104 </div>  <!-- cp-mv-intermediate-dirs -->
1105 <div class="h4" id="cp-mv-intermediate-dirs" title="cp-mv-intermediate-dirs">
1106 <h4>Creation of intermediate directories with copy/move
1107     (<em>client and server</em>)</h4>
1108
1109 <p>See the section on the new <a href="#>intermediate-directories</a>"
1110 >--parents option</a> for more about this.</p>
1111
1112 </div>  <!-- cp-mv-intermediate-dirs -->
1113
1114 </div>  <!-- copy-move-improvements -->
1115
1116 <div class="h3" id="cancellation-improvements"
1117      title="cancellation-improvements">
1118 <h3>Cancellation improvements (<em>client</em>)</h3>
1119
1120 <p>Clients operations are now significantly more responsive to
1121 cancellation (e.g. via <tt>control-c</tt>).  In pre-1.5 releases,
1122 after directing an operation to stop, one sometimes had to wait for
1123 some time (e.g. while I/O occurred) before the operation would
1124 actually stop.</p>
1125
1126 </div>  <!-- cancellation-improvements -->
1127
1128 <div class="h3" id="cmdline" title="cmdline">
1129 <h3>Command-line client improvements (<em>client</em>)</h3>
1130
1131 <p>There are far too many enhancements and new options to the
1132 command-line client to list them all here.  Aside from all the ones
1133 mentioned already in these release notes, below are a few more that we
1134 consider important, but please see the 1.5.0 section in the <a
1135 href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
1136 for a complete list.</p>
1137
1138 <div class="h4" id="resolve" title="resolve">
1139 <h4>New "resolve" subcommand replaces "resolved"</h4>
1140
1141 <p>A new <strong><tt>resolve</tt></strong> subcommand replaces the
1142 "<tt>resolved</tt>" subcommand (the latter is deprecated, but still
1143 present for compatibility).  The new subcommand takes a
1144 <strong><tt>--accept=orig|mine|repo</tt></strong> option to select
1145 which version of a file to retain (which means Subversion now supports
1146 batch-style conflict resolution).</p>
1147
1148 <p>See <a
1149 href="http://subversion.tigris.org/issues/show_bug.cgi?id=2784" >issue
1150 #2784</a> for more.</p>
1151
1152 </div>  <!-- resolve -->
1153
1154 <div class="h4" id="intermediate-directories"
1155              title="intermediate-directories">
1156 <h4>Create intermediate directories if asked</h4>
1157
1158 <p>Add, mkdir, copy, and move take a new
1159 <strong><tt>--parents</tt></strong> option, which makes intermediate
1160 directories as necessary to create the destination path.</p>
1161
1162 <p>See <a
1163 href="http://subversion.tigris.org/issues/show_bug.cgi?id=1776" >issue
1164 #1776</a> for more</p>
1165
1166 </div>  <!-- intermediate-directories -->
1167
1168 <div class="h4" id="keep-local" title="keep-local">
1169 <h4>New --keep-local option retains path after delete.</h4>
1170
1171 <p>Delete (remove) now takes a
1172 <strong><code>--keep-local</code></strong> option to retain its
1173 targets locally, so paths will not be removed even if unmodified.</p>
1174
1175 </div>  <!-- keep-local -->
1176
1177 <div class="h4" id="commit-revprops" title="commit-revprops">
1178 <h4>Commit now takes a --with-revprop option.</h4>
1179
1180 Commit now takes a <strong><tt>--with-revprop</tt></strong> option
1181 allowing one to set revision properties
1182
1183 <p>See <a
1184 href="http://subversion.tigris.org/issues/show_bug.cgi?id=1976" >issue
1185 #1976</a> for more.</p>
1186
1187 </div>  <!-- commit-revprops -->
1188
1189 </div>  <!-- cmdline -->
1190
1191 <div class="h3" id="dav-modules" title="dav-modules">
1192 <h3>Easier to try out experimental <tt>ra_serf</tt> DAV access module
1193 (<em>client</em>)</h3>
1194
1195 <p>Subversion 1.4 introduced the experimental <tt>ra_serf</tt>
1196 repository access module for accessing HTTP[S] DAV Subversion servers.
1197 This uses the <a href="http://code.google.com/p/serf/">serf</a>
1198 library instead of the Neon library which the original DAV support
1199 uses.  serf supports pipelined requests which may lead to better
1200 performance.  However, Subversion 1.4 required you to choose which
1201 module to use for accessing DAV servers at build time, which made it
1202 difficult to find out which module performs better for your usage
1203 patterns.</p>
1204
1205 <p>Subversion 1.5 allows you to build both modules at the same time;
1206 you can choose which library to use on a global or host-by-host basis
1207 by setting the <tt>http-library</tt> variable in your run-time server
1208 configuration file (<tt>~/.subversion/servers</tt>).  In recognition
1209 of the fact that both libraries are DAV clients, we have
1210 renamed <tt>ra_dav</tt> to <tt>ra_neon</tt>.</p>
1211
1212 </div>  <!-- dav-modules -->
1213
1214 <div class="h3" id="apis" title="apis">
1215 <h3>API changes, improvements and language bindings
1216     (<em>client and server</em>)</h3>
1217
1218 <p>There are too many new and revised APIs in Subversion 1.5.0 to even
1219 begin to list them all here.  See the <a
1220 href="http://svn.collab.net/svn-doxygen/" >Subversion API
1221 Documentation</a> page for general API information.  If you develop a
1222 3rd-party client application that uses Subversion APIs, you should
1223 probably look at the header files for the interfaces you use and see
1224 what's changed.</p>
1225
1226 <p>One general change is that most APIs that formerly took a
1227 <tt>recurse</tt> parameter have been upgraded to accept a
1228 <tt>depth</tt> parameter instead, to enable the new <a
1229 href="#sparse-checkouts">sparse checkouts</a> feature.</p>
1230
1231 <p>Language bindings have mostly been updated for the new APIs, though
1232 some may lag more than others.</p>
1233
1234 </div>  <!-- apis -->
1235
1236 <div class="h3" id="bug-fixes" title="bug-fixes">
1237 <h3>Bug fixes (<em>client and server</em>)</h3>
1238
1239 <p>A great many bugs have been fixed.  See the 1.5.0 section in the <a
1240 href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
1241 for details.</p>
1242
1243 </div>  <!-- bug-fixes -->
1244
1245 </div>  <!-- enhancements -->
1246
1247 <div class="h2" id="svn-1.3-deprecation" title="svn-1.3-deprecation">
1248 <h2>Subversion 1.3.x series no longer supported</h2>
1249
1250 <p>The Subversion 1.3.x line is no longer supported.  This doesn't
1251 mean that your 1.3 installation is doomed; if it works well and is all
1252 you need, that's fine.  "No longer supported" just means we've stopped
1253 accepting bug reports against 1.3.x versions, and will not make any
1254 more 1.3.x bugfix releases, except perhaps for absolutely critical
1255 security or data-loss bugs.</p>
1256
1257 </div>  <!-- svn-1.3-deprecation -->
1258
1259 </div>  <!-- app -->
1260 </body>
1261 </html>