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">
5
<style type="text/css"> /* <![CDATA[ */
6
@import "branding/css/tigris.css";
7
@import "branding/css/inst.css";
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>
18
<h1 style="text-align: center">Subversion 1.5 Release Notes</h1>
20
<div class="h2" id="news" title="news">
21
<h2>What's New in Subversion 1.5</h2>
24
<li><a href="#merge-tracking"
25
>Merge tracking (foundational)</a></li>
26
<li><a href="#sparse-checkouts"
27
>Sparse checkouts (via new <tt>--depth</tt> option)</a></li>
28
<li><a href="#interactive-conflict-resolution"
29
>Interactive conflict resolution</a></li>
30
<li><a href="#changelists"
31
>Changelist support</a></li>
32
<li><a href="#externals"
33
>Relative URLs, peg revisions in <tt>svn:externals</tt></a></li>
34
<li><a href="#cyrus-sasl"
35
>Cyrus SASL support for ra_svn and <tt>svnserve</tt></a></li>
36
<li><a href="#fsfs-sharding"
37
>Improved support for large deployments on FSFS, via sharding</a></li>
38
<li><a href="#fsfs-isolate-immutable"
39
>Improved FSFS optimizability, via immutable file isolation</a></li>
40
<li><a href="#webdav-proxy"
41
>WebDAV transparent write-through proxy</a></li>
42
<li><a href="#copy-move-improvements"
43
>Improvements to <tt>copy</tt> and <tt>move</tt></a></li>
44
<li><a href="#cancellation-improvements"
45
>Speed improvements, cancellation response improvements</a></li>
46
<li><a href="#dav-modules"
47
>Easier to try experimental <tt>ra_serf</tt> DAV access module</a></li>
49
>API changes, improvements, and much language bindings work</a></li>
50
<li><a href="#bug-fixes"
51
>More than 150 new bug fixes, enhancements</a></li>
54
<p>Subversion 1.5 is a superset of all previous Subversion releases,
55
and is considered the current "best" release. Any feature or bugfix
56
in 1.0.x through 1.4.x is also in 1.5, but 1.5 contains features and
57
bugfixes not present in any earlier release. The new features will
58
eventually be documented in a 1.5 version of the free Subversion book,
59
see <a href="http://svnbook.red-bean.com" >svnbook.red-bean.com</a>.</p>
63
<div class="h2" id="compatibility" title="compatibility">
64
<h2>Compatibility Concerns</h2>
66
<p>Older clients and servers interoperate transparently with 1.5
67
servers and clients. However, some of the new 1.5 features (e.g., <a
68
href="#merge-tracking" >merge tracking</a>) may not be available
69
unless both client and server are the latest version . There are also
70
cases (e.g., <a href="#sparse-checkouts">sparse checkouts</a>) where a
71
new feature will work but will run less efficiently if the client is
72
new and the server old.</p>
74
<p>There is <strong>no need</strong> to dump and reload your
75
repositories. Subversion 1.5 can read repositories created by earlier
76
versions. To upgrade an existing installation, just install the
77
newest libraries and binaries on top of the older ones.</p>
79
<p>Subversion 1.5 maintains API/ABI compatibility with earlier
80
releases, by only adding new functions, never removing old ones. A
81
program written to the 1.0, 1.1, 1.2, 1.3, or 1.4 API can both compile
82
and run using 1.5 libraries. However, a program written for 1.5
83
cannot necessarily compile or run against older libraries.</p>
85
<div class="h3" id="new-feature-compatibility-table"
86
title="new-feature-compatibility-table">
87
<h3>New Feature Compatibility Table</h3>
91
<th>Minimum Client</th>
92
<th>Minimum Server</th>
93
<th>Minimum Repository</th>
96
<td><a href="#merge-tracking">Merge tracking</a></td>
102
<td><a href="#sparse-checkouts">Sparse checkouts</a></td>
108
<td><a href="#interactive-conflict-resolution">Interactive conflict resolution</a></td>
114
<td><a href="#changelists">Changelist support</a></td>
120
<td><a href="#externals">Relative URLs, peg revisions in <tt>svn:externals</tt></a></td>
126
<td><a href="#cyrus-sasl"> Cyrus SASL support for ra_svn and <tt>svnserve</tt></a></td>
127
<td>any<sup>*</sup>, 1.5</td>
128
<td>any<sup>*</sup>, 1.5</td>
130
<td><sup>*</sup>Limited, see <a href="#sasl-compatibility">SASL and <code>svn://</code> compatibility</a></td></tr>
132
<td><a href="#fsfs-sharding"> Improved support for large deployments on FSFS, via sharding</a></td>
133
<td>any<sup>*</sup>, 1.5</td>
136
<td><sup>*</sup>1.5 required for <code>file://</code> compatibility</td></tr>
138
<td><a href="#fsfs-isolate-immutable">Improved FSFS optimizability, via immutable file isolation</a></td>
139
<td>any<sup>*</sup>, 1.5</td>
142
<td><sup>*</sup>1.5 required for <code>file://</code> compatibility</td></tr>
144
<td><a href="#webdav-proxy">WebDAV transparent write-through proxy</a></td>
146
<td>1.5<sup>*</sup></td>
148
<td><sup>*</sup>Apache 2.2 server also required</td></tr>
150
<td><a href="#copy-move-improvements">Improvements to <tt>copy</tt> and <tt>move</tt></a></td>
152
<td>any<sup>*</sup>, 1.5</td>
154
<td><sup>*</sup>Limited, see <a href="#copy-move-improvements">Copy/move<tt>-</tt>related improvements</a></td></tr>
156
<td><a href="#cancellation-improvements">Speed improvements, cancellation response improvements</a></td>
162
<td><a href="#dav-modules">Easier to try experimental <tt>ra_serf</tt> DAV access module</a></td>
169
</div> <!-- new-feature-compatibility-table -->
171
<div class="h3" id="wc-and-repos-format-change"
172
title="wc-and-repos-format-change">
173
<h3>Working Copy and Repository Format Changes</h3>
175
<p>The working copy format has been upgraded. This means that 1.4 and
176
older Subversion clients will <em>not</em> be able to work with
177
working copies produced by Subversion 1.5. Working copies are <a
178
href="#wc-upgrades" >upgraded automatically</a>.</p>
180
<p>Similarly, the repository format has changed, meaning that 1.4 and
181
older versions of Subversion tools that normally access a repository
182
directly (e.g. <tt>svnserve</tt>, <tt>mod_dav_svn</tt>,
183
<tt>svnadmin</tt>) won't be able to read a repository created by
184
Subversion 1.5. But, repositories are <a href="#repos-upgrades"
185
><strong>not</strong> upgraded automatically</a>.</p>
187
<div class="h4" id="wc-upgrades" title="wc-upgrades">
188
<h4>Working Copy Upgrades</h4>
190
<p><strong>WARNING:</strong> if a Subversion 1.5 client encounters a
191
pre-1.5 working copy, it will <em>automatically</em> upgrade the
192
working copy format as soon as it touches it, making it unreadable by
193
older Subversion clients. If you are using several versions of
194
Subversion on your machine, be careful about which version you use in
195
which working copy, to avoid accidentally upgrading a working copy.
196
(But note that this "auto upgrade" behavior does <em>not</em> occur
197
with the <a href="#repos-upgrades" >repositories</a>, only working
200
<p>If you accidentally upgrade a 1.4 working copy to 1.5, and wish to
201
downgrade back to 1.4, use the <a
202
href="http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py"
203
><tt>change-svn-wc-format.py</tt></a> script. See <a
204
href="http://subversion.tigris.org/faq.html#working-copy-format-change"
205
>this FAQ entry</a> for details, and run the script with the
206
<code>--help</code> option for usage instructions.</p>
208
</div> <!-- wc-upgrades -->
210
<div class="h4" id="repos-upgrades" title="repos-upgrades">
211
<h4>Repository Upgrades</h4>
213
<p>The Subversion 1.5 server works with 1.4 and older repositories,
214
and it will <em>not</em> upgrade such repositories to 1.5 unless
215
specifically requested to via the
216
<strong><code>svnadmin upgrade</code></strong> command. This means
217
that some of the new 1.5 features will not become available simply by
218
upgrading your server: you will also have to upgrade your
219
repositories. (We decided not to auto-upgrade repositories because we
220
didn't want 1.5 to silently make repositories unusable by
221
1.4 — that step should be a conscious decision on the
222
part of the repository admin.)</p>
224
<p>After running <strong><code>svnadmin upgrade</code></strong>,
225
you may wish to also run the <a
226
href="http://svn.collab.net/repos/svn/trunk/tools/server-side/svn-populate-node-origins-index.c"
227
>svn-populate-node-origins-index</a> program on the repository.
228
Subversion 1.5 maintains a node-origins index for each repository, and
229
builds the index lazily as the information is needed. But for old
230
repositories with lots of revisions, it's better to create the index
231
in one step, using the aforementioned tool, than to have live queries
232
be slower until the index has built itself. See <a
233
href="http://subversion.tigris.org/issues/show_bug.cgi?id=3024" >issue
234
#3024</a> for details.</p>
236
</div> <!-- repos-upgrades -->
238
</div> <!-- wc-and-repos-format-change -->
240
<div class="h3" id="output-changes" title="output-changes">
241
<h3>Command Line Output Changes</h3>
243
<p>Although we try hard to keep output from the command line programs
244
compatible between releases, new information sometimes has to be
245
added. This can break scripts that rely on the exact format of the
246
output. Unfortunately, we are not able to enumerate all of the output
247
changes in 1.5, but one of them is that conflict markers in files now
248
match the file's defined eol-style.</p>
250
</div> <!-- output-changes -->
252
<div class="h3" id="sasl-compatibility" title="sasl-compatibility">
253
<h3>SASL and <code>svn://</code> compatibility</h3>
255
<p>All 1.x clients, with or without Cyrus SASL support, will be able to
256
authenticate against all 1.x servers that do not have Cyrus SASL enabled.
257
Note that the <tt>CRAM-MD5</tt> and <tt>ANONYMOUS</tt> mechanisms are
258
built into Subversion, so you'll be able to use them even if the
259
corresponding Cyrus SASL plugins are missing.</p>
261
<p>1.x clients without Cyrus SASL support will be able to authenticate
262
against 1.5+ servers with SASL enabled, provided the server allows the
263
<tt>CRAM-MD5</tt> and/or <tt>ANONYMOUS</tt> mechanisms.</p>
265
<p>1.5+ clients with Cyrus SASL support will be able to authenticate against
266
1.5+ servers with SASL enabled, provided at least one of the mechanisms
267
supported by the server is also supported by the client.</p>
269
<p>See <a href="#cyrus-sasl" >this section</a> for more information on
270
using Cyrus SASL with Subversion.</p>
272
</div> <!-- sasl-compatibility -->
274
<div class="h3" id="revprops-compatibility" title="revprops-compatibility">
275
<h3>Custom revprops may now need to be examined by <tt>pre-commit</tt>
278
<p>Each revision in Subversion has a set of <q>revision properties</q>
279
associated with it; in addition to the standard log message, author,
280
and date, arbitrary user-defined properties can be set. These
281
properties are not themselves versioned, so there is no way to revert
282
changes to them. Because of this, you cannot modify revprops on a
283
committed revision without setting up a <tt>pre-revprop-change</tt>
284
hook on the server. Before Subversion 1.5, only the three standard
285
revprops could be set at commit time; administrators using hooks to
286
control the contents of the three standard revprops needed to check
287
during <tt>pre-commit</tt> and <tt>pre-revprop-change</tt>, but for
288
custom revprops, only <tt>pre-revprop-change</tt> appeared
291
<p>Subversion 1.5 adds
292
a <a href="#commit-revprops"><tt>--with-revprop</tt> option to <tt>svn
293
commit</tt></a> which allows users to specify revprops for revisions
294
as they commit them. Thus, in Subversion 1.5, it is possible for
295
revproperties to be set on revisions without
296
any <tt>pre-revprop-change</tt>. The <tt>pre-commit</tt> hook can
297
examine the transaction's revision properties before it is committed
298
(just like many servers already use <tt>pre-commit</tt> to check for
299
properly formatted log messages, e.g.).</p>
301
<p>This means that if you previously relied
302
on <tt>pre-revprop-change</tt> to control the ability to write to
303
revprops (as opposed to just keeping track of their history), you may
304
want to add similar controls to <tt>pre-commit</tt>.</p>
306
</div> <!-- revprops-compatibility -->
309
</div> <!-- compatibility -->
311
<div class="h2" id="new-features" title="new-features">
312
<h2>New Features</h2>
314
<div class="h3" id="merge-tracking" title="merge-tracking">
315
<h3>Merge tracking (foundational) (<em>client and server</em>)</h3>
317
<p><em>Merge tracking</em> means Subversion keeps track of what
318
changes have been merged where. This reduces the overhead involved in
319
maintaining branches, and gives users a way to inquire what changes
320
are merged — or are available to be
321
merged — on different lines of development.</p>
323
<p>The merge tracking support in Subversion 1.5 is "foundational": its
324
basic functionality is implemented, but there are still parts of our
325
<a href="http://subversion.tigris.org/merge-tracking/" >original
326
spec</a> that remain to be done, and merging is sometimes too slow.
327
There will be merge tracking improvements in Subversion 1.5.1 and
328
afterwards. In the meantime:</p>
331
<li><p>Take a look at <a href="#mt-known-issues"
332
>the list of known issues</a></p></li>
334
href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword"
335
>"The Final Word on Merge Tracking"</a> in the Subversion Book</p></li>
337
href="http://www.collab.net/community/subversion/articles/merge-info.html"
338
>"Understanding the internals of Subversion's merge tracking feature"</a>
339
by Paul Burba</p></li>
342
<div class="h4" id="mt-overview" title="mt-overview">
345
<p>Subversion's merge tracking is designed to:</p>
348
<li>Reduce the bookkeeping overhead for branch maintenance</li>
349
<li>Avoid common cases of the "repeated merge" problem</li>
350
<li>Allow for cherry-picking of changes</li>
353
<p>Each changeset is identified by its revision number, and merged
354
changesets are recorded in the new
355
<strong><code>svn:mergeinfo</code></strong> property (known colloquially
356
as "mergeinfo") set on the destination of the merge. Subversion keeps
357
mergeinfo up-to-date automatically, but there is also a way to <a
358
href="#mt-record-only" >record/unrecord merges manually</a>, since
359
there will always be cases where a human knows something that
360
Subversion doesn't.</p>
362
</div> <!-- mt-overview -->
364
<div class="h4" id="mt-ui" title="mt-ui">
365
<h4>User interface</h4>
367
<p>Merging changes from (say) trunk to a branch no longer requires
368
that you specify the revision range. Instead, each time you want to
369
sync up with trunk, you can just do:</p>
371
<pre> $ cd BRANCH_WORKING_COPY
372
$ svn merge URL_TO_TRUNK</pre>
374
<p>Subversion will figure out what changes from URL_TO_TRUNK have not
375
yet been merged and pull in just those changes. When it's time to
376
merge the branch back to trunk, do this:</p>
378
<pre> $ cd TRUNK_WORKING_COPY
379
$ svn merge --reintegrate URL_TO_BRANCH</pre>
381
<p>Below is a more formal description of all the
382
merge-tracking-related interface changes.</p>
384
<p>The <strong><code>svn merge</code></strong> command takes two new
385
options: <strong><code>--record-only</code></strong> and
386
<strong><code>--reintegrate</code></strong>.</p>
388
<div id="mt-record-only" title="mt-record-only">
389
<p>The --record-only option works with -r and does exactly what you
390
think it does: it marks a revision as merged (or unmerged, if using
391
the "-" revision number negation syntax), without actually changing
392
anything besides the mergeinfo. For example, this would be useful
393
when someone has hand-edited a file in such a way as to effectively
394
incorporate a change that was already made somewhere else. Rather
395
than have the original change be ported over in the next
396
synchronization merge, thus risking textual conflicts wherever the two
397
versions trivially differ, you can just record the change as already
399
href="http://subversion.tigris.org/merge-tracking/requirements.html#manual-merge"
400
>the merge-tracking requirements</a>, and <a
401
href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges"
402
>Blocking Changes</a> in the Subversion book, for more details.)</p>
403
</div> <!-- mt-record-only -->
405
<div id="mt-reintegrate" title="mt-reintegrate">
406
<p>The --reintegrate option is used when merging a branch back to
407
trunk; it checks for some common safeguard conditions and then does
408
the merge in a fast and efficient way. See <a
409
href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync"
410
>Keeping a branch in sync</a> in the Subversion book for more.</p>
411
</div> <!-- mt-reintegrate -->
413
<p>The new <strong><code>svn mergeinfo</code></strong> command can
414
show which changesets a directory has absorbed and which changesets
415
it's still eligible to receive. See <a
416
href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.mergeinfo"
417
>Mergeinfo and Previews</a> in the Subversion book for more information.</p>
419
<p>The <strong><code>svn log</code></strong> and
420
<strong><code>svn blame</code></strong> commands take a new
421
<strong><code>-g</code></strong>
422
(<strong><code>--use-merge-history</code></strong>) option, which tells
423
them to take mergeinfo into account. Without this option, they won't.</p>
425
<p>The reason for the -g option is that it is sometimes useful to
426
ignore merge history. In blame output you sometimes want to see the
427
person B who merged a change, though other times you want to see the
428
person A who originally wrote the change that B later merged; use -g
429
to get the latter information. In log output, you sometimes want to
430
see exactly the revisions that were committed on a given line of
431
development, though other times you want to see, as part of the same
432
output, the original changes that were later ported as merge
433
revisions; again, -g includes the latter information (tagged with
434
lines that say "<tt>Merged via: </tt>" followed by the revision number
435
in which the merge took place). See <a
436
href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.logblame"
437
>Merge-Sensitive Logs and Annotations</a> in the Subversion book for
440
</div> <!-- mt-ui -->
442
<div class="h4" id="mt-compatibility" title="mt-compatibility">
443
<h4>Merge tracking and compatibility</h4>
445
<p>As described earlier, merge-tracking is not supported unless you <a
446
href="#repos-upgrades" >upgrade the repository</a> as well as the
449
<p>If you were using the <a
450
href="http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/"
451
>svnmerge</a> wrapper program to do merging, and now want to switch to
452
using Subversion 1.5's native merge-tracking, then you should use the
454
href="http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/svnmerge-migrate-history.py"
455
>svnmerge-migrate-history.py</a> script to convert svnmerge's custom
456
properties to the <tt>svn:mergeinfo</tt> properties that Subversion
459
</div> <!-- mt-compatibility -->
461
<div class="h4" id="mt-known-issues" title="mt-known-issues">
462
<h4>Known Issues</h4>
464
<p>There are still known issues with merge tracking in 1.5.0. We're
465
working on the most important ones first, which are:</p>
468
<li><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3128"
469
>issue #3128</a>: <code>merge --reintegrate</code> should handle
471
<li><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2897"
472
>issue #2897</a>: proper support for reflective merges</li>
473
<li><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3126"
474
>issue #3126</a>: better change-availability reporting
475
(<code>svn mergeinfo</code> shows too few or too many eligible
477
<li><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2837"
478
>issue #2837</a>: allow merge tracking to be useful when performing
480
<li><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3056"
481
>issue #3056</a>: avoid repeat merge in an intelligent way</li>
482
<li><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2898"
483
>issue #2898</a>: handle mergeinfo when deleting/adding children
484
you don't have access to</li>
485
<li><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3067"
486
>issue #3067</a>: subtrees that don't exist at the start or end of
487
a merge range shouldn't break the merge</li>
488
<li><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3157"
489
>issue #3157</a>: merging a change from a path's natural history
490
creates self-referential mergeinfo</li>
491
<li><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3174"
492
>issue #3174</a>: merge algorithm chokes on subtrees needing
493
special attention that have been renamed</li>
497
href="http://subversion.tigris.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&keywords=merge-tracking&keywords_type=anytokens"
498
>list of merge-tracking-related open issues</a> and the <a
499
href="http://subversion.tigris.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&short_desc=merg&short_desc_type=substring"
500
>list of all merge-related open issues</a>, though note that not all
501
of merge-related issues are about merge-tracking and many predate it.)</p>
503
<p><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3157"
504
>Issue #3157</a> is particularly easy to run into, so here's a more
505
detailed explanation of what the issue is and how to work around
508
<p>Merge tracking information currently can include the "natural
509
history" of a path. One situation where this happens is when creating
510
a <tt>branch</tt> from <tt>trunk</tt> at a certain revision <tt>X</tt>
511
and later merging all changes from <tt>branch</tt> back to
512
<tt>trunk</tt>, without explicitly limiting the merge range and
513
without using the <a href="#mt-reintegrate"
514
><code>--reintegrate</code> option</a>. Afterwards, the merge
515
tracking information on <tt>trunk</tt> will list revisions before
516
<tt>X</tt>. This does no harm to future merge operations, but
517
thereafter <code>svn log -g</code> on <tt>trunk</tt> will report these
518
revisions from the "natural history", which is typically not expected.
519
This is because <code>svn log -g</code> uses the merge tracking
520
information from previous revisions (not only from HEAD).</p>
522
<p>Note that this should not be a problem with release branches (also
523
called "maintenance branches"), because one typically does not merge
524
them back to trunk. Instead, recommended practice is for new changes
525
to enter on trunk and be ported outward to the branches that need the
526
changes. However, you could run into this problem with a feature
527
branch, which would be merged back to trunk once, at the end of the
528
branch's lifetime.</p>
530
<p>One workaround is to correct the merge tracking information before
531
committing the merged revision, by reverse merging the "natural
532
history" information: <code>svn merge --record-only -rX:1</code>.
533
Another solution is to avoid this situation entirely, by explicitly
534
specifying merge ranges in the first place, e.g.: <tt>-rX:HEAD</tt>.
536
href="http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=139379"
537
>this mail</a> for more information.</p>
539
<p>When merging a feature branch, the best solution is to <a
540
href="#mt-reintegrate" >use the <code>--reintegrate</code> option</a>;
541
then this problem won't happen in the first place.</p>
543
</div> <!-- mt-known-issues -->
545
<div class="h4" id="mt-further-reading" title="mt-further-reading">
546
<h4>Further reading</h4>
548
<p>For more on merge-tracking in Subversion 1.5, see:</p>
551
<li><a href="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html"
552
>Chapter 4: Branching and Merging</a> in the Subversion book
554
<li><a href="http://blog.red-bean.com/sussman/?p=92" >Subversion 1.5
555
merge-tracking in a nutshell</a> (blog post by Ben Collins-Sussman)
557
<li><a href="http://subversion.tigris.org/merge-tracking/" >The merge
558
tracking design documents</a>
559
(requirements, use cases, functional spec, design)
563
</div> <!-- mt-further-reading -->
565
</div> <!-- merge-tracking -->
567
<div class="h3" id="sparse-checkouts" title="sparse-checkouts">
568
<h3>Sparse checkouts (<em>client and server</em>)</h3>
570
<p>Many users have very large trees of which they only want to
571
checkout certain parts. In previous versions of Subversion,
572
<code>checkout -N</code> was not really up to this task. Subversion
573
1.5 introduces the <strong><code>--depth</code></strong> option to the
574
<strong><code>checkout</code></strong>,
575
<strong><code>switch</code></strong>, and
576
<strong><code>update</code></strong> subcommands. This option
577
replaces <code>-N</code>, and allows users to construct working
578
copies containing just what's needed, leaving out everything else.</p>
580
<div class="h4" id="sc-depth" title="sc-depth">
581
<h4>Depth overview</h4>
582
<p>Each directory now understands the notion of <em>depth</em>, which has
583
four possible values: <tt>empty</tt>, <tt>files</tt>, <tt>immediates</tt>,
584
<tt>infinity</tt>. The values are defined as follows:</p>
588
<td><tt>empty</tt></td>
589
<td>Updates will not pull in any files or subdirectories not already
593
<td><tt>files</tt></td>
594
<td>Updates will pull in any files not already present, but not
598
<td><tt>immediates</tt></td>
599
<td>Updates will pull in any files or subdirectories not already present;
600
the new subdirectories will have depth-empty.</td>
603
<td><tt>infinity</tt></td>
604
<td>Updates will pull in any files or subdirectories not already present;
605
the new subdirectories will have depth-infinity. Equivalent to today's
606
default update behavior.</td>
610
<p>The <code>--depth</code> option sets depth values as it updates the working
611
copy, tweaking new subdirectories' depth values as described above.</p>
613
</div> <!-- sc-depth -->
615
<div class="h4" id="sc-ui" title="sc-ui">
616
<h4>User Interface</h4>
617
<p>Affected commands:</p>
619
<li><code>checkout</code></li>
620
<li><code>switch</code></li>
621
<li><code>update</code></li>
622
<li><code>status</code></li>
623
<li><code>info</code></li>
626
<p>The <code>-N</code> option becomes a synonym for <code>--depth=files</code>
627
for these commands. This changes the existing <code>-N</code> behavior for
628
these commands, but in a trivial way (see below).</p>
630
<p><code>checkout</code> without <code>--depth</code> or
631
<code>-N</code> behaves the same as it does today.
632
<code>switch</code> and <code>update</code> without
633
<code>--depth</code> or <code>-N</code> behave the same way as today
634
if and only if the working copy is fully depth-infinity.
635
<code>switch</code> and <code>update</code> without
636
<code>--depth</code> or <code>-N</code> will <em>not</em> change depth
637
values (exception: a missing directory specified on the command line
638
will be pulled in).</p>
640
<p>Thus, <code>checkout</code> is identical to <code>checkout
641
--depth=infinity</code>, but <code>switch</code> and <code>update</code> are
642
not the same as <code>switch --depth=infinity</code> and <code>update
643
--depth=infinity</code>. The former update entries according to existing depth
644
values, while the latter pull in everything.</p>
646
<p>To get started, run <code>checkout</code> with
647
<code>--depth=empty</code> or <code>--depth=files</code>. If
648
additional files or directories are desired, pull them in with
649
<code>update</code> commands using appropriate <code>--depth</code>
650
options. The <code>svn status</code> command should list the ambient
651
depths of directories, in addition to whatever other statuses are
652
listed. The <code>svn info</code> command also lists ambient depth,
653
when invoked on a directory whose depth is not the default
656
<p><strong>Note:</strong> There is currently no <em>deselection</em>
657
interface for sparse checkouts — that is, there is no
658
command to unselect or "fold up" a subdirectory after you've brought
659
it into a sparse working copy (although there are some fairly easy
660
workarounds to achieve the same effect). See <a
661
href="http://subversion.tigris.org/issues/show_bug.cgi?id=2843" >issue
662
#2843</a> for details.</p>
664
</div> <!-- sc-ui -->
666
<div class="h4" id="sc-compat" title="sc-compat">
667
<h4>Compatibility with older servers</h4>
669
<p>The new <tt>--depth</tt> feature naturally requires the client to
670
be 1.5+, and will work most efficiently if the server is also 1.5+.
671
However, the client will still behave correctly if the server is 1.4.x
672
or lower; things will just be less efficient.</p>
674
<p>This is because older servers do not
675
understand — and therefore
676
ignore — what the client tells them about "depth". So
677
when a client requests a depth shallower than depth-infinity, older
678
servers will send back more data than the client wants. However, a
679
1.5+ client will know it's talking to an older server and filter out
680
this extra data. Thus, operations may take a while, because the
681
server sends a lot of data over the network that the client then
682
ignores, but the final result on the client side will be the same.
683
(Note that older servers understand a <tt>recurse</tt> flag in the
684
network protocols, and 1.5+ clients send that flag based on the depth;
685
this alleviates some of the extra network traffic penalty.)</p>
687
</div> <!-- sc-compat -->
689
<div class="h4" id="sc-further-reading" title="sc-further-reading">
690
<h4>Further reading</h4>
694
href="http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html"
695
>Sparse Directories</a> section in the Subversion book.
698
href="http://svn.collab.net/repos/svn/trunk/notes/sparse-directories.txt"
699
>design/implementation document</a> in the repository.</li>
702
</div> <!-- sc-further-reading -->
704
</div> <!-- sparse-checkouts -->
706
<div class="h3" id="interactive-conflict-resolution"
707
title="interactive-conflict-resolution">
708
<h3>Interactive Conflict Resolution (<em>client</em>)</h3>
710
<p>Conflict resolution is now done interactively by the command-line
712
<code>update</code>/<code>switch</code>/<code>merge</code>
713
subcommands, and the client library offers a callback function so
714
other clients can do similarly.</p>
716
<p>Here's an example using the command-line client:</p>
720
U contrib/client-side/svnmerge/svnmerge_test.py
721
Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
722
Select: (p) postpone, (df) diff-full, (e) edit,
723
(s) show all options: s
724
(p) postpone - mark the conflict to be resolved later
725
(df) diff-full - show all changes made to merged file
726
(e) edit - change merged file in an editor
727
(r) resolved - accept merged version of file
728
(mf) mine-full - accept my version of entire file (ignore their changes)
729
(tf) theirs-full - accept their version of entire file (lose my changes)
730
(l) launch - launch external tool to resolve conflict
731
(s) show all - show this list
733
Select: (p) postpone, (df) diff-full, (e) edit,
734
(s) show all options: tf
735
G contrib/client-side/svnmerge/svnmerge.py
736
Updated to revision 25685.
740
<p>This feature can be selectively disabled by using the --non-interactive
741
option, or disabled permanently by setting '[miscellany] interactive-conflicts
742
= no' in your run-time config file.</p>
744
<p>The API for interactive conflict resolution is exposed via a
745
callback function and the following new data types:</p>
748
<li><code>svn_wc_conflict_resolver_func_t</code>, the callback API
750
<li><code>svn_wc_conflict_description_t</code>, a description of the
751
conflict passed to the callback</li>
752
<li><code>svn_wc_conflict_action_t</code>, the part of the conflict
753
description indicating what the merge was trying to do</li>
754
<li><code>svn_wc_conflict_reason_t</code>, the part of the conflict
755
description indicating the type of conflict</li>
756
<li><code>svn_wc_conflict_result_t</code>, returned by the callback
757
as the result of any conflict resolution attempt</li>
758
<li><code>svn_wc_conflict_choice_t</code>, an enum indicating what
759
course of action the user chose</li>
762
<p>Clients provide their callback function to Subversion's libraries
763
by setting it on the (new) <code>conflict_func</code> field of their
764
<code>svn_client_ctx_t</code>, and may provide additional state to the
765
callback via the corresponding <code>conflict_baton</code> field.</p>
767
</div> <!-- interactive-conflict-resolution -->
769
<div class="h3" id="changelists" title="changelists"> <h3>Changelist
770
support (<em>client</em>)</h3> <p>The Subversion client now contains
771
the notion of a <em>changelist</em>: a group of files which are
772
associated with a chosen name. This becomes especially useful when
773
working on several different set of files within the same working
774
copy. Instead of having to remember each file in each set, Subversion
775
1.5 will allow you to associate a changelist with each set of files.
776
Most commands which take a set of files as targets will now also
777
accept the <strong><code>--changelist</code></strong> option, which
778
filters those targets based upon the members of the changelist.
779
Changelist membership can be edited using the new
780
<strong><code>changelist</code></strong> subcommand.</p>
782
<p>Changelists are handled entirely by the client. They are never sent
783
to the server, and aren't visible to other users of the same repository.
784
Also, the <code>--changelist</code> option is never additive; if a file
785
wouldn't have been included in the list of targets without
786
<code>--changelist</code>, it will not be added to it, regardless of membership
787
in the changelist. Currently, a file may only be in one changelist at a
788
time, and directories can not be members of a changelist.</p>
790
<p>The <code>--changelist</code> option is supported by the following
793
<li><code>changelist</code></li>
794
<li><code>commit</code></li>
795
<li><code>diff</code> (only wc-wc and wc-repos cases)</li>
796
<li><code>info</code></li>
797
<li><code>propget</code></li>
798
<li><code>proplist</code></li>
799
<li><code>propset</code></li>
800
<li><code>propdel</code></li>
801
<li><code>revert</code></li>
802
<li><code>status</code></li>
803
<li><code>update</code></li>
806
<div class="h4" id="cl-further-reading" title="cl-further-reading">
807
<h4>Further reading</h4>
811
href="http://svnbook.red-bean.com/nightly/en/svn.advanced.changelists.html"
812
>Changelists</a> section in the Subversion book.
815
href="http://svn.collab.net/repos/svn/trunk/notes/changelist-design.txt"
816
>design/implementation document</a> in the repository.</li>
819
</div> <!-- cl-further-reading -->
821
</div> <!-- changelists -->
823
<div class="h3" id="externals" title="externals">
824
<h3>Relative URLs, peg revisions in <tt>svn:externals</tt>
825
(<em>client</em>)</h3>
827
<p>Two additions to the <tt>svn:externals</tt> feature</p>
829
<div class="h4" id="externals-peg-revs" title="externals-peg-revs">
830
<h4>Peg revision syntax for URLs</h4>
832
<p><em>Compatibility and the new syntax:</em> For compatibility
833
reasons, the pre-1.5 svn:externals syntax continues to not understand
834
peg revisions. A new format has been introduced to allow peg
835
revisions in URLs.</p>
837
<p>The old format of</p>
839
foo http://example.com/repos/zig
840
foo/bar -r 1234 http://example.com/repos/zag
843
<p>does not support peg revisions, and the following externals will
844
not work (unless there are directories named <tt>zig@HEAD</tt> and
845
<tt>zag@HEAD</tt>):</p>
848
foo http://example.com/repos/zig@HEAD
849
foo/bar -r 1234 http://example.com/repos/zag@HEAD
852
<p>The new format moves the URL first followed by the directory the
853
external is checked out or exported into; if there is an operative
854
(-r) revision, it precedes the URL. Here are four externals lines:</p>
857
http://example.com/repos/zig foo1
858
-r 1234 http://example.com/repos/zag foo/bar1
859
http://example.com/repos/zig@HEAD foo2
860
-r 1234 http://example.com/repos/zag@HEAD foo/bar2
863
<p>In other words, both operative ("-r") and peg ("@") revisions are
864
allowed, but neither is required.</p>
866
</div> <!-- externals-peg-revisions -->
868
<div class="h4" id="externals-relative-urls" title="externals-relative-urls">
869
<h4>Support for relative URLs</h4>
871
<p>Prior to Subversion 1.5, the URLs in an <tt>svn:externals</tt>
872
specification must be absolute. Now they can be relative. Four
873
different relative externals specifications are supported. (In the
874
following examples, assume we have two repositories: one at
875
<tt>http://example.com/svn/repos-1</tt> and another at
876
<tt>http://example.com/svn/repos-2</tt>. We have a checkout of
877
<tt>http://example.com/svn/repos-1/project1/trunk</tt> and the
878
<tt>svn:externals</tt> property is set on <tt>trunk</tt>.)</p>
880
<dl><dt><strong>../</strong></dt>
881
<dd><p>Relative to the directory with the <tt>svn:externals</tt>
882
property. These URLs always begin with the string <tt>../</tt>, for
885
../../project2/trunk common/project2/trunk
889
<tt>http://example.com/svn/repos-1/project2/trunk</tt> into
890
<tt>common/project2/trunk</tt>. The external's URL is relative to the
891
URL of the directory with the <tt>svn:externals</tt> property, not the
892
directory where the external is written to disk.</p></dd>
894
<dt><strong>^/</strong></dt>
896
<dd><p>Relative to the repository root.</p>
899
^/project2/trunk common/project2/trunk
903
<tt>http://example.com/svn/repos-1/project2/trunk</tt> into
904
<tt>common/project2/trunk</tt>.</p>
906
<p>You can also refer to other repositories easily using repository
907
root relative URLs:</p>
910
^/../repos-2/foo/trunk common/foo/trunk
913
<p>This will extract <tt>http://example.com/svn/repos-2/foo/trunk</tt>
914
into <tt>common/foo/trunk</tt>.</p>
917
<dt><strong>//</strong></dt>
919
<dd><p>Relative to the scheme. This copies the scheme of the checkout
920
or export URL into the URL in <tt>svn:externals</tt>. It is useful
921
when the same hostname must the accessed with different schemes
922
depending upon network location; i.e. clients in the intranet use
923
<tt>http://</tt> while external clients use <tt>svn+ssh://</tt>.</p>
926
//example.com/svn/repos-1/project2/trunk common/project2/trunk
930
<tt>http://example.com/svn/repos-1/project2/trunk</tt> into
931
<tt>common/project2/trunk</tt>. If the working copy was checked out
932
from <tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt> then
934
<tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt>.</p>
937
<dt><strong>/</strong></dt>
939
<dd><p>Server root relative URLs. This copies the scheme and hostname
940
from the checkout or export URL into the <tt>svn:externals</tt>
944
/svn/repos-1/project2/trunk common/project2/trunk
948
<tt>http://example.com/svn/repos-1/project2/trunk</tt> into
949
<tt>common/project2/trunk</tt>. If the working copy was checked out
950
from <tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt> then
952
<tt>svn+ssh://example.com/svn/repos-1/project1/trunk</tt>.</p>
957
<p>Relative URLs are still supported in the old <tt>svn:externals</tt>
958
format (that does not support peg revisions).</p>
960
<p>When Subversion sees an <tt>svn:externals</tt> without an absolute
961
URL, it takes the first argument as a relative URL and the second as
962
the target directory.</p>
964
</div> <!-- externals-relative-urls -->
966
<div class="h4" id="externals-further-reading"
967
title="externals-further-reading">
968
<h4>Further reading</h4>
971
href="http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html"
972
>svn:externals</a> section of the Subversion Book.</p>
974
</div> <!-- externals-further-reading -->
976
</div> <!-- externals -->
978
<div class="h3" id="cyrus-sasl" title="cyrus-sasl">
979
<h3>Cyrus SASL support for ra_svn and <tt>svnserve</tt> (<em>client
980
and server</em>)</h3>
983
href="http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer">
984
Wikipedia</a>: "SASL is a framework for authentication and data security in
985
Internet protocols. It decouples authentication mechanisms from application
986
protocols, in theory allowing any authentication mechanism supported by SASL to
987
be used in any application protocol that uses SASL."</p>
989
<p>In practice, the server sends a list of authentication mechanisms that it
990
supports. The client then selects one of these mechanisms based on what the
991
client supports, and informs the server of its decision. After that, a
992
number of messages are exchanged until either authentication succeeds or an
993
error occurs. In the latter case, the client is allowed to restart
996
<p>The <tt>svn://</tt> protocol has always supported this type of negotiation.
997
However, only the <tt>CRAM-MD5</tt> and <tt>ANONYMOUS</tt> mechanisms were
998
implemented. <a href="http://asg.web.cmu.edu/sasl/">Cyrus SASL</a> supports
999
all these, and, in addition, provides a host of other mechanisms such as
1000
<tt>DIGEST-MD5</tt>, OTP (One-Time Passwords), GSSAPI (used for Kerberos
1001
authentication), NTLM (NT LAN Manager), SRP (Secure Remote Password), and
1002
others. The exact list of available mechanisms depends on how SASL was
1003
compiled, as many of them either have external dependencies, or are not
1004
built by default. Also, because each mechanism is actually a shared library
1005
that is dynamically loaded at runtime, many distributions package these
1006
mechanisms separately from the core library.</p>
1008
<p>Please see the <a href="#sasl-compatibility">compatibility
1009
section</a> for information regarding using a 1.5 SASL-enabled server
1010
with pre-1.5 clients. More information about Subversion's SASL
1011
support can be found in <a
1012
href="http://svn.collab.net/repos/svn/trunk/notes/sasl.txt"
1015
</div> <!-- cyrus-sasl -->
1017
<div class="h3" id="fsfs-sharding" title="fsfs-sharding">
1018
<h3>Improved support for large deployments on FSFS, via sharding
1019
(<em>server</em>)</h3>
1021
<p>The FSFS filesystem backend stores each revision in its own file, and prior
1022
to Subversion 1.5, all of these files were stored in a common directory in
1023
the repository. Now, <em>newly created</em> FSFS repositories will use a
1024
two-level directory tree with up to (by default) 1000 files per directory.
1025
These repositories will only be compatible with other Subversion 1.5 clients,
1026
but of course, Subversion 1.5 will be able to continue using repositories
1027
employing the older scheme without any problem.</p>
1029
<p>The primary reason for the change is to allow the revision count to
1030
grow beyond the filesystem's (efficient) directory entry limit. While
1031
modern filesystems can support millions of entries per directory, they
1032
become slower and common administrative tools (e.g. directory
1033
listings, backups) become unwieldy or fail completely.</p>
1035
<p>For more information about the technical underpinnings of FSFS sharding,
1036
see this <a href="http://www.farside.org.uk/200704/tree_structured_fsfs">blog
1038
<!-- ### Reshard script is not quite finished and currently
1039
### aborts if you try to run it.
1041
href="http://svn.collab.net/repos/svn/trunk/tools/server-side/fsfs-reshard.py"
1042
>Migration script</a> provided.
1046
<p>The shard size can by adjusted by editing the
1047
"<code>layout sharded</code>" line in "db/format" after
1048
<code>svnadmin create</code> but before populating the
1051
</div> <!-- fsfs-sharding -->
1053
<div class="h3" id="fsfs-isolate-immutable" title="fsfs-isolate-immutable">
1054
<h3>Improved FSFS optimizability, via immutable file isolation
1055
(<em>server</em>)</h3>
1057
<p>The FSFS repositories never change a revision after it is written
1058
to the disk. Although this should allow the operating system to cache
1059
these files forever, certain filesystems (e.g. NFS) prohibit such
1060
caching by default. Now the FSFS repository layout has been changed
1061
such that the immutable files are confined to the subdirectories
1062
"db/revs" and "db/txn-protorevs". This allows these directories to be
1063
on a mount point where caching is enabled (on Linux look at the
1064
"nocto" option to nfs(5)).</p>
1066
<p>Since commit transactions are now built up in "db/txn-protorevs"
1067
instead of "db/transactions", the latter directory no longer needs to
1068
be on the same mount point. If the repository is stored on a slower
1069
filesystem (e.g. NFS), then commit performance can be improved by
1070
moving the transactions directory to local disk (using a symbolic
1071
link). If you are using multiple svn servers behind a network load
1072
scaler, you must configure the load scaler to direct to the same
1073
server for the duration of the transaction. This is typically called
1074
"client affinity".</p>
1076
</div> <!-- fsfs-isolate-immutable -->
1078
<div class="h3" id="webdav-proxy" title="webdav-proxy">
1079
<h3>WebDAV transparent write-through proxy (<em>server</em>)</h3>
1081
<p>Subversion 1.4 <a
1082
href="http://subversion.tigris.org/svn_1.4_releasenotes.html#svnsync">
1083
introduced <tt>svnsync</tt></a> — a tool which
1084
provided the ability to replicate repository history from one
1085
repository to another. Though useful, <tt>svnsync</tt> could only
1086
pull revision history from a repository, not push additional commits
1087
back to the master. Subversion 1.5 adds WebDAV proxy support to
1088
<tt>mod_dav_svn</tt>, effectively allowing bidirectional revision
1089
history replication between master servers and slave servers using
1090
<tt>mod_dav_svn</tt>.</p>
1092
<p>All clients interact with a slave server, but the slave transparently
1093
passes all of the write-oriented activites to the master (rewriting the
1094
content as necessary). The slaves are essentially read-only, but they
1095
do have a complete copy of the repository locally. This serves to
1096
alleviate read traffic from the master server which may be desirable
1097
in certain circumstances.</p>
1099
<p>This model has several advantages to using a straight HTTP DAV-aware
1100
caching proxy, in that each slave can respond to all read-only requests
1101
without ever having to relay them to the master backend.</p>
1103
<div class="h4" id="webdav-proxy-requirements"
1104
title="webdav-proxy-requirements">
1105
<h4>Requirements</h4>
1107
<li>Subversion 1.5 or newer.</li>
1108
<li>Apache HTTP Server 2.2.0 or higher with mod_proxy enabled.
1109
(Several fixes to mod_proxy were committed for this patch that were not
1110
backported to the 2.0 branch of httpd.)</li>
1113
</div> <!-- webdav-proxy-requirements -->
1115
<div class="h4" id="webdav-proxy-example" title="webdav-proxy-example">
1116
<h4>Example configuration</h4>
1118
<p>Participants:</p>
1120
<li>Slave → <tt>slave.example.com</tt> (there can be many!)</li>
1121
<li>Master → <tt>master.example.com</tt> (there can only be one!)</li>
1122
<li>A WebDAV client (<tt>ra_neon</tt>, <tt>ra_serf</tt>, other WebDAV
1126
<p>Each client does:</p>
1128
% svn co http://slave.example.com/repos/slave/
1133
<p>(The client can perform all operations as normal.)</p>
1135
<p>Each slave has:</p>
1137
<Location /repos/slave>
1139
SVNPath /my/local/copy/of/repos
1140
SVNMasterURI http://master.example.com/repos/master/
1144
<p>The master MUST have a post-commit hook that updates all of the slaves. An
1145
example that does this using <code>svnadmin dump</code>/<code>svnadmin
1146
load</code> and ssh is provided below. <tt>svnsync</tt> can probably do the
1149
<p>Additionally, if locks are permitted on the master repository, lock
1150
databases need to kept in sync via post-lock and post-unlock hooks on
1151
the master pushing the lock state to the slaves. (Username
1152
preservation is left as an exercise to the reader. Translation: <a
1153
href="hacking.html#patches">patches to these notes are most
1154
welcome</a>.) If the lock database is not propogated, users will not
1155
be able to accurately determine whether a lock is
1156
held — but locking will still work.</p>
1158
<p>A sample synchronization script may look like this:</p>
1163
SLAVE_HOST=slave.example.com
1164
SLAVE_PATH=/my/local/copy/of/repos
1166
# Ensure svnadmin is in $PATH on both this machine and the remote server!
1167
svnadmin dump --incremental -r$2 $1 > /tmp/$2.dump
1168
scp /tmp/$2.dump $SLAVE_HOST:$SLAVE_PATH
1169
ssh $SLAVE_HOST "svnadmin load $SLAVE_PATH < $SLAVE_PATH/$2.dump"
1170
ssh $SLAVE_HOST "rm $SLAVE_PATH/$2.dump"
1174
</div> <!-- webdav-proxy-example -->
1176
<div class="h4" id="webdav-proxy-further-reading"
1177
title="webdav-proxy-further-reading">
1178
<h4>Further reading</h4>
1180
<p>Additional information about WebDAV proxy support is available <a
1181
href="http://svn.collab.net/repos/svn/trunk/notes/webdav-proxy">in the
1184
</div> <!-- webdav-proxy-further-reading -->
1186
</div> <!-- webdav-proxy -->
1188
</div> <!-- new-features -->
1191
<div class="h2" id="enhancements" title="enhancements">
1192
<h2>Enhancements and Bugfixes</h2>
1194
<div class="h3" id="copy-move-improvements" title="copy-move-improvements">
1195
<h3>Copy/move-related improvements (<em>client and server</em>)</h3>
1197
<p>The abilities and behavior of <code>copy</code> and
1198
<code>move</code> operations are significantly improved in 1.5+.</p>
1200
<div class="h4" id="leverage-copyfrom" title="leverage-copyfrom">
1201
<h4>Improved copy-handling during updates (<em>client and server</em>)</h4>
1203
<p>A common problem in older versions of Subversion was the way in
1204
which <code>svn update</code> handled incoming copies and moves.</p>
1206
<p>Consider this scenario: Harry runs <code>svn move foo bar; svn
1207
commit</code>, and meanwhile Sally makes local changes to 'foo', and
1208
then runs <code>svn update</code>. In earlier versions of Subversion,
1209
the server would send down a completely new file 'bar', and unversion
1210
the file 'foo' (if it had no uncommitted changes, Subversion would
1211
remove it entirely.) From Sally's point of view, her changes seem to
1212
be lost; the newly added 'bar' file has the older content, and the
1213
file 'foo' has been taken out of version control.</p>
1215
<p>In Subversion 1.5, the client and server both attempt to be smarter
1216
about this. The server doesn't send a whole new file during the
1217
update, but rather instructions to copy something that likely already
1218
exists in the working copy. So Sally's 'foo' file is copied to 'bar'
1219
(with local edits intact!).</p>
1221
<p>In theory, this is the best-case scenario. There are a few
1222
caveats: this "proper copying" of existing working-copy resources only
1223
works on files, not (yet) on directories. Also, if an incoming
1224
move-operation deletes 'foo' before it attempts to copy it to 'bar',
1225
then the copy will fail, and the client reverts to the old behavior of
1226
fetching a pristine copy of the file from the repository. We hope to
1227
address this in svn 1.6.</p>
1230
href="http://subversion.tigris.org/issues/show_bug.cgi?id=503" >issue
1231
#503</a> for more.</p>
1233
</div> <!-- leverage-copyfrom -->
1235
<div class="h4" id="copy-peg-revs" title="copy-peg-revs">
1236
<h4>Peg revisions (<em>client</em>)</h4>
1238
<p>Copy and move operations now accept sources with peg ("@")
1242
href="http://subversion.tigris.org/issues/show_bug.cgi?id=2546" >issue
1243
#2546</a> for more.</p>
1245
</div> <!-- copy-peg-revs -->
1247
<div class="h4" id="multi-op-copy-move" title="multi-op-copy-move">
1248
<h4>Multiple working copy copy/move operations (<em>client</em>)</h4>
1250
<p>Clients may now perform chained copy/move operations locally on a
1251
single object in a working copy:</p>
1259
href="http://subversion.tigris.org/issues/show_bug.cgi?id=756" >issue
1260
#756</a> for more.</p>
1262
</div> <!-- multi-op-copy-move -->
1264
<div class="h4" id="multi-src-copy" title="multi-src-copy">
1265
<h4>Improved handling multiple copy/move sources (<em>client</em>)</h4>
1267
<p>Clients now accept multiple sources for copy and move operations, with
1268
the ability to copy/move each of the sources to the specified directory.
1269
This mirrors the behavior of standard command-line copy and move tools,
1270
such as <code>cp</code> and <code>mv</code>. For example:</p>
1273
svn mkdir new_subdir
1274
svn mv foo.txt bar.txt baz.txt new_subdir
1277
<p>In practice, this means users can take advantage of shell globbing
1278
when doing a local copy or move:</p>
1284
<p>Multiple source copy/move also works for all previously defined
1285
copy/move working copy and repository combinations.</p>
1288
href="http://subversion.tigris.org/issues/show_bug.cgi?id=747" >issue
1289
#747</a> for more.</p>
1291
</div> <!-- multi-src-copy -->
1293
<div class="h4" id="cp-takes-base" title="cp-takes-base">
1294
<h4>Copy takes -rBASE (<em>client</em>)</h4>
1296
<p>Copy now understands the special revision "BASE" in a working copy
1297
(as in: "<tt>-rBASE</tt>").</p>
1300
href="http://subversion.tigris.org/issues/show_bug.cgi?id=1643" >issue
1301
#1643</a> for more.</p>
1303
</div> <!-- cp-takes-base -->
1305
<div class="h4" id="cp-mv-intermediate-dirs" title="cp-mv-intermediate-dirs">
1306
<h4>Creation of intermediate directories with copy/move
1307
(<em>client and server</em>)</h4>
1309
<p>See the section on the new <a href="#intermediate-directories"
1310
>--parents option</a> for more about this.</p>
1312
</div> <!-- cp-mv-intermediate-dirs -->
1314
</div> <!-- copy-move-improvements -->
1316
<div class="h3" id="cancellation-improvements"
1317
title="cancellation-improvements">
1318
<h3>Cancellation improvements (<em>client</em>)</h3>
1320
<p>Clients operations are now significantly more responsive to
1321
cancellation (e.g. via <tt>control-c</tt>). In pre-1.5 releases,
1322
after directing an operation to stop, one sometimes had to wait for
1323
some time (e.g. while I/O occurred) before the operation would
1326
</div> <!-- cancellation-improvements -->
1328
<div class="h3" id="cmdline" title="cmdline">
1329
<h3>Command-line client improvements (<em>client</em>)</h3>
1331
<p>There are far too many enhancements and new options to the
1332
command-line client to list them all here. Aside from all the ones
1333
mentioned already in these release notes, below are a few more that we
1334
consider important, but please see the 1.5.0 section in the <a
1335
href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
1336
for a complete list.</p>
1338
<div class="h4" id="resolve" title="resolve">
1339
<h4>New "resolve" subcommand replaces "resolved"</h4>
1341
<p>A new <strong><tt>resolve</tt></strong> subcommand replaces the
1342
"<tt>resolved</tt>" subcommand (the latter is deprecated, but still
1343
present for compatibility). The new subcommand takes a
1344
<strong><tt>--accept=orig|mine|repo</tt></strong> option to select
1345
which version of a file to retain (which means Subversion now supports
1346
batch-style conflict resolution).</p>
1349
href="http://subversion.tigris.org/issues/show_bug.cgi?id=2784" >issue
1350
#2784</a> for more.</p>
1352
</div> <!-- resolve -->
1354
<div class="h4" id="intermediate-directories"
1355
title="intermediate-directories">
1356
<h4>Create intermediate directories if asked</h4>
1358
<p>Add, mkdir, copy, and move take a new
1359
<strong><tt>--parents</tt></strong> option, which makes intermediate
1360
directories as necessary to create the destination path.</p>
1363
href="http://subversion.tigris.org/issues/show_bug.cgi?id=1776" >issue
1364
#1776</a> for more</p>
1366
</div> <!-- intermediate-directories -->
1368
<div class="h4" id="keep-local" title="keep-local">
1369
<h4>New --keep-local option retains path after delete.</h4>
1371
<p>Delete (remove) now takes a
1372
<strong><code>--keep-local</code></strong> option to retain its
1373
targets locally, so paths will not be removed even if unmodified.</p>
1375
</div> <!-- keep-local -->
1377
<div class="h4" id="commit-revprops" title="commit-revprops">
1378
<h4>Commit now takes a --with-revprop option.</h4>
1380
Commit now takes a <strong><tt>--with-revprop</tt></strong> option
1381
allowing one to set revision properties
1384
href="http://subversion.tigris.org/issues/show_bug.cgi?id=1976" >issue
1385
#1976</a> for more.</p>
1387
</div> <!-- commit-revprops -->
1389
</div> <!-- cmdline -->
1391
<div class="h3" id="dav-modules" title="dav-modules">
1392
<h3>Easier to try out experimental <tt>ra_serf</tt> DAV access module
1393
(<em>client</em>)</h3>
1395
<p>Subversion 1.4 introduced the experimental <tt>ra_serf</tt>
1396
repository access module for accessing HTTP[S] DAV Subversion servers.
1397
This uses the <a href="http://code.google.com/p/serf/">serf</a>
1398
library instead of the Neon library which the original DAV support
1399
uses. serf supports pipelined requests which may lead to better
1400
performance. However, Subversion 1.4 required you to choose which
1401
module to use for accessing DAV servers at build time, which made it
1402
difficult to find out which module performs better for your usage
1405
<p>Subversion 1.5 allows you to build both modules at the same time;
1406
you can choose which library to use on a global or host-by-host basis
1407
by setting the <tt>http-library</tt> variable in your run-time server
1408
configuration file (<tt>~/.subversion/servers</tt>). In recognition
1409
of the fact that both libraries are DAV clients, we have
1410
renamed <tt>ra_dav</tt> to <tt>ra_neon</tt>.</p>
1412
</div> <!-- dav-modules -->
1414
<div class="h3" id="apis" title="apis">
1415
<h3>API changes, improvements and language bindings
1416
(<em>client and server</em>)</h3>
1418
<p>There are too many new and revised APIs in Subversion 1.5.0 to even
1419
begin to list them all here. See the <a
1420
href="http://svn.collab.net/svn-doxygen/" >Subversion API
1421
Documentation</a> page for general API information. If you develop a
1422
3rd-party client application that uses Subversion APIs, you should
1423
probably look at the header files for the interfaces you use and see
1426
<p>One general change is that most APIs that formerly took a
1427
<tt>recurse</tt> parameter have been upgraded to accept a
1428
<tt>depth</tt> parameter instead, to enable the new <a
1429
href="#sparse-checkouts">sparse checkouts</a> feature.</p>
1431
<p>Language bindings have mostly been updated for the new APIs, though
1432
some may lag more than others.</p>
1434
</div> <!-- apis -->
1436
<div class="h3" id="bug-fixes" title="bug-fixes">
1437
<h3>Bug fixes (<em>client and server</em>)</h3>
1439
<p>A great many bugs have been fixed. See the 1.5.0 section in the <a
1440
href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
1443
</div> <!-- bug-fixes -->
1445
</div> <!-- enhancements -->
1447
<div class="h2" id="svn-1.3-deprecation" title="svn-1.3-deprecation">
1448
<h2>Subversion 1.3.x series no longer supported</h2>
1450
<p>The Subversion 1.3.x line is no longer supported. This doesn't
1451
mean that your 1.3 installation is doomed; if it works well and is all
1452
you need, that's fine. "No longer supported" just means we've stopped
1453
accepting bug reports against 1.3.x versions, and will not make any
1454
more 1.3.x bugfix releases, except perhaps for absolutely critical
1455
security or data-loss bugs.</p>
1457
</div> <!-- svn-1.3-deprecation -->
1459
<div class="h2" id="deps" title="deps">
1460
<h2>Subversion Dependencies Distribution: Binary Compatibility Issues</h2>
1462
<div class="h3" id="deps-background" title="deps-background">
1465
<p>APR 0.9.x and 1.x are binary-incompatible. This means if you are
1466
already using Subversion with APR 0.9.x, and then upgrade your libapr
1467
to 1.X <em>without rebuilding Subversion</em>, things will break.
1468
Things will also break if your Subversion server libraries are linked
1469
to one version of APR but your Apache HTTPD server is linked to a
1470
different version.</p>
1472
<p>For a long time, Subversion's main source distribution included APR
1473
0.9.x, which was the latest available at the time, along with a few
1474
other things (e.g., Neon, zlib) that weren't yet widespread on
1475
installation systems.</p>
1477
</div> <!-- deps-background -->
1479
<div class="h3" id="deps-now" title="deps-now">
1480
<h3>Subversion 1.5.0 Dependencies Distribution</h3>
1482
<p>Today, these dependencies are no longer exotic, so our source
1483
distribution contains just Subversion itself. Those building
1484
Subversion are expected to have the necessary libraries already
1485
installed, or to be able to fetch them easily. But for convenience,
1486
we still offer a "deps" distribution: it doesn't contain Subversion,
1487
it just has source code for those third-party libraries.</p>
1489
<p>Until Subversion 1.5.0, the deps distribution contained APR 0.9.x,
1490
but as of 1.5.0, we're finally upgrading it to APR 1.x. This is
1491
because by now there are very few systems that will have binary
1492
compatibility issues, and of those, few are likely to build using the
1495
<p>If you already have a Subversion installation using APR 0.9.x, it's
1496
still possible to move to APR 1.x safely (although you are not
1497
required to, unless you use the deps dist). Just be sure to recompile
1498
Subversion, and Apache httpd if necessary, after upgrading APR.</p>
1500
<p>Note that it's perfectly safe to use APR 1.x from the beginning.
1501
In fact, we recommend it. If you're building Subversion for the first
1502
time, there's no compatibility issue to worry about, so just grab the
1503
latest version of APR (or use our deps dist).</p>
1505
</div> <!-- deps-now -->
1507
</div> <!-- deps -->
added
removed
debian/svn_1.5_releasenotes.html
