/usr/share/doc/subversion/svn_1.7_releasenotes.html is in subversion 1.8.10-6+deb8u6.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<title>Apache Subversion 1.7 Release Notes</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css">
@import url("/style/site.css");
</style>
</head>
<body>
<div id="copyright">
<p>Copyright © 2011 <a href="http://www.apache.org/">The Apache
Software Foundation</a>, Licensed under
the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache
License, Version 2.0</a>. Apache, Apache Subversion, and
the Apache feather logo are trademarks of The Apache Software
Foundation. Subversion and the Apache Subversion logo are
registered trademarks of The Apache Software Foundation.</p>
</div> <!-- #copyright -->
</div> <!-- #site-nav -->
<div id="site-content">
<div id="site-notice">
<!-- PUT SITE-WIDE NOTICES HERE AS NECESSARY -->
</div> <!-- #site-notice -->
<!-- **************** BEGIN CONTENT ***************** -->
<h1 style="text-align: center">Apache Subversion 1.7 Release Notes</h1>
<div class="h2" id="news">
<h2>What's New in Apache Subversion 1.7
<a class="sectionlink" href="#news" title="Link to this section">¶</a>
</h2>
<ul>
<li><a href="#wc-ng">Working Copy Metadata Storage Improvements</a></li>
<li><a href="#httpv2">Improved HTTP protocol usage</a></li>
<li><a href="#svnrdump">New remote dumpfile tool: <tt>svnrdump</tt></a></li>
<li><a href="#patch">New feature: svn patch</a></li>
<li><a href="#enhancements">Many enhancements and bug fixes</a></li>
<li><a href="#issues">Known issues in the release</a></li>
<li><a href="#distribution-changes">Dependency, license and distribution changes</a></li>
</ul>
<p>Apache Subversion 1.7 is a superset of all previous Subversion
releases, and is as of the time of its release considered the current
"best" release. Any feature or bugfix in 1.0.x through 1.6.x is also
in 1.7, but 1.7 contains features and bugfixes not present in any
earlier release. The new features will eventually be documented in a
1.7 version of the free Subversion book
(<a href="http://svnbook.red-bean.com/">svnbook.red-bean.com</a>).</p>
<p>This page describes only major changes. For a complete list of
changes, see the 1.7 section of the <a href="http://svn.apache.org/repos/asf/subversion/trunk/CHANGES">CHANGES</a>
file.</p>
</div> <!-- news -->
<div class="h2" id="compatibility">
<h2>Compatibility Concerns
<a class="sectionlink" href="#compatibility" title="Link to this section">¶</a>
</h2>
<p>Older clients and servers interoperate transparently with 1.7
servers and clients. However, some of the new 1.7 features may not be
available unless both client and server are the latest version. There are
also cases where a new feature will work but will run less efficiently if
the client is new and the server old.</p>
<p>There is <strong>no need</strong> to dump and reload your
repositories. Subversion 1.7 servers can read and write to repositories created by
earlier versions. To upgrade an existing server installation, just install the
newest libraries and binaries on top of the older ones.</p>
<p>Subversion 1.7 servers use the same repository format as Subversion 1.6.
Therefore, it is possible to seamlessly upgrade and downgrade between 1.6.x and 1.7.x
servers without changing the format of the on-disk repositories.
(This is not correct in general for any pair of 1.x and 1.y servers,
but happens to hold for 1.6 and 1.7.)
If new 1.7 features were enabled on the server (in the hooks or server
configuration files), they will, of course, have to be disabled prior
to reverting back to a 1.6 server.</p>
<p>Subversion 1.7 clients use a new working copy format.
Subversion 1.7 clients cannot use Subversion 1.6 (and earlier) working copies.
Existing working copies created with Subversion 1.6 and earlier need to be
upgraded before they can be used with a Subversion 1.7
client (see <a href="#wc-ng">below</a> for details).</p>
<p>Subversion 1.7 maintains API/ABI compatibility with earlier
releases, by only adding new functions, never removing old ones. A
program written to any previous 1.x API can both compile
and run using 1.7 libraries. However, a program written for 1.7
cannot necessarily compile or run against older libraries.</p>
<p>There may be limited cases where the behavior of old APIs has been
slightly modified from previous releases. These are cases where edge cases
of the functionality has been deemed buggy, and therefore improved or removed.
Please consult the
<a href="http://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.7/">API errata</a> for more detailed information on what these APIs are
and what impact these changes may have. For Subversion 1.7, these
errata are mostly limited to <code>libsvn_wc</code>, with one notable
exception: <code>libsvn_ra_serf</code>'s approach to driving
the <code>svn_delta_editor_t</code> interfaces (provided to it indirectly
via calls to the <code>svn_ra.h</code> interfaces).</p>
<div class="h3" id="new-feature-compatibility-table">
<h3>New Feature Compatibility Table
<a class="sectionlink" href="#new-feature-compatibility-table" title="Link to this section">¶</a>
</h3>
<table border="1">
<tbody><tr>
<th>New Feature</th>
<th>Minimum Client<sup>1</sup></th>
<th>Minimum Server</th>
<th>Minimum Repository</th>
<th>Notes</th></tr>
<tr>
<td><a href="#httpv2">HTTPv2</a></td>
<td>1.7</td>
<td>1.7</td>
<td>any</td>
<td>Permutations of older client/server combinations will continue to
function at the pre-1.7 feature level. Server-side configuration
changes might be required for optimal performance with clients that
use <a href="#serf">serf</a>.</td></tr>
<tr>
<td><a href="#wc-ng">WC-NG</a></td>
<td>1.7</td>
<td>any</td>
<td>any</td>
<td>1.6 working copies cannot be used with 1.7 and will
<strong>not</strong> be upgraded to the new 1.7 format
automatically.</td></tr>
<tr>
<td><a href="#svnrdump">svnrdump</a></td>
<td>1.7</td>
<td>1.4 (dump)<br>1.7 (load)</td>
<td>any</td>
<td>See <a href="#svnrdump">the full entry, below</a> for discussion
of known issues.</td></tr>
<tr>
<td><a href="#patch">svn patch</a></td>
<td>1.7</td>
<td>any</td>
<td>any</td>
<td></td></tr>
<tr>
<td><a href="#atomic-revprops">atomic revprop changes</a></td>
<td>1.7</td>
<td>1.7</td>
<td>any</td>
<td>Fixes a race condition in <tt>svnsync</tt> (<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3546">issue #3546</a>).</td></tr>
<tr>
<td><a href="#subtree-mergeinfo-recording">reduced subtree mergeinfo
recording</a></td>
<td>1.7</td>
<td>any</td>
<td>any</td>
<td>If both pre-1.7 clients and 1.7 clients are used to perform merges
to the same branch, the pre-1.7 clients may experience slower merge
performance.</td></tr>
<tr>
<td><a href="#server-performance-tuning">server performance tuning</a></td>
<td>any</td>
<td>1.7</td>
<td>any</td>
<td>Purely server-side configuration. file:// access in 1.7 clients will
use the default settings.</td></tr>
<tr>
<td colspan="5"><sup>1</sup>Reminder: when using the <tt>file://</tt>
repository access method, the Subversion program is both the client
<em>and</em> the server.</td></tr>
</tbody></table>
</div> <!-- new-feature-compatibility-table -->
<div class="h3" id="output-changes">
<h3>Command Line Output Changes
<a class="sectionlink" href="#output-changes" title="Link to this section">¶</a>
</h3>
<p>Although we try hard to keep output from the command line programs
compatible between releases, new information sometimes has to be
added. This can break scripts that rely on the exact format of the
output. For this reason, we encourage programs which consume the output
of the commandline client to consider using the <tt>--xml</tt> option,
or accessing Subversion through the various bindings interfaces.</p>
<!-- Insert items here, of the following form:
<div class="h4" id="foo">
<h4>Improved output of <tt>svn foo</tt>
<a class="sectionlink" href="#foo"
title="Link to this section">¶</a>
</h4>
<p>The output of <tt>svn foo</tt> has been improved. The following
example illustrates these changes.</p>
<pre>
$ svn foo
BAR
BAZ
BLAH
BIN
$
</pre>
</div>
-->
<div class="h4" id="multi-update">
<h4>Improved output of <tt>svn update</tt> for multiple working copies
<a class="sectionlink" href="#multi-update" title="Link to this section">¶</a>
</h4>
<p>Improvements have been made to the output of <tt>svn update</tt>
when updating multiple working copies at once (see
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3693">issue #3693</a>). Below is an example of the new output:</p>
<pre> $ svn up subversion svncorp UNVERSIONED
Updating 'subversion':
At revision 1037740.
Updating 'svncorp':
At revision 288.
Skipped 'UNVERSIONED'
Summary of updates:
Updated 'subversion' to r1037740.
Updated 'svncorp' to r288.
Summary of conflicts:
Skipped paths: 1
</pre>
</div> <!-- multi-update -->
<div class="h4" id="diff-properties">
<h4><tt>svn diff</tt> now shows property changes as unidiff
<a class="sectionlink" href="#diff-properties" title="Link to this section">¶</a>
</h4>
<p><tt>svn diff</tt> now shows textual property changes in unidiff format,
except for <tt>svn:mergeinfo</tt> properties.
Below is an example of the new output:</p>
<pre> $ svn diff
Index: gamma
===================================================================
--- gamma (revision 23)
+++ gamma (working copy)
Property changes on: gamma
___________________________________________________________________
Modified: svn:externals
## -1,3 +1,3 ##
^/branches/gamma gamma-external
-^/trunk/alpha alpha-external
+^/trunk/beta beta-external
^/trunk/epsilon epsilon-external
Index: beta
===================================================================
--- beta (revision 23)
+++ beta (working copy)
Property changes on: beta
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
</pre>
</div> <!-- diff-properties -->
<div class="h4" id="error-numbers">
<h4>Error and warning numbers now reported
<a class="sectionlink" href="#error-numbers" title="Link to this section">¶</a>
</h4>
<p>The output of <tt>svn</tt> now contains an error number or warning
number with every error. The following example illustrates these changes.</p>
<pre> % svn info
svn: E155007: '/home/CIA-91' is not a working copy
</pre>
<p>These error values are useful as search keywords. Under the hood, these error
codes correspond to the <a href="http://subversion.apache.org/docs/api/latest/svn__error__codes_8h_source.html">API error codes</a> used by Subversion and APR. For programming to our API's,
it's possible to convert a numeric error code to a symbolic one via the <a href="https://svn.apache.org/repos/asf/subversion/tools/client-side/which-error.py">which-error.py</a> script (first included in Subversion 1.3.0):</p>
<pre> % ./tools/dev/which-error.py 155007
00155007 SVN_ERR_WC_NOT_DIRECTORY
</pre>
</div>
</div> <!-- output-changes -->
<div class="h3" id="compat-misc">
<h3>Miscellaneous Compatibility Notes
<a class="sectionlink" href="#compat-misc" title="Link to this section">¶</a>
</h3>
<p>There are some additional specific areas where changes made in this
release might necessitate further adjustment by administrators or
users. We'll cover those in this section.</p>
<div class="h4" id="case-sensitive-authz">
<h4>Case sensitivity of authz access rules
<a class="sectionlink" href="#case-sensitive-authz" title="Link to this section">¶</a>
</h4>
<p>Prior to this release, the section headers in Subversion's authz
access files—which contain repository names and repository
filesystem paths—were parsed in a case-insensitive fashion.
That's been fixed in this release. The practical fallout, though, is
that your existing authz files might be depending (perhaps
unintentionally) on the old behavior and the new behavior could result
in access to items in your repositories being unexpectedly
denied—or granted—as a result of upgrading to Subversion
1.7. Please review all authz access files for case correctness. (For
details,
see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3781">issue #3781</a>).</p>
</div> <!-- case-sensitive-authz -->
<div class="h4" id="revprop-packing">
<h4>Incompatible FSFS changes since 1.7.0-alpha3 for packed repositories
<a class="sectionlink" href="#revprop-packing" title="Link to this section">¶</a>
</h4>
<p>Subversion 1.6 introduced support for <a href="http://subversion.apache.org/docs/release-notes/1.6.html#fsfs-packing">packing
FSFS revision files</a>, and Subversion 1.7.x alpha releases (up to
1.7.0-alpha3) supported packing of revprops into an SQLite database. This
support is not present in the final release (see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3952">issue #3952</a> for the reason). Any
FSFS-backed repositories that were <tt>svnadmin create</tt>d or
<tt>svnadmin upgrade</tt>d by <tt>svnadmin</tt> from a nightly build or
from an alpha release of the 1.7.x line are <strong>not</strong> supported by
the final 1.7.0 release. It is required to <tt>dump</tt> these repositories
using an <tt>svnadmin</tt> built from the 1.7.0-alpha3 release (or to
<tt>svnsync</tt> them using a source server running 1.7.0-alpha3) in order to
upgrade them for the 1.7.0 release.</p>
<p>Subversion 1.7 will complain when it encounters such repositories, with
the following error:</p>
<pre>subversion/libsvn_fs_fs/fs_fs.c:1083: (apr_err=160043)
svnadmin: E160043: Found format '5', only created by unreleased dev builds;
see <a href="http://subversion.apache.org/docs/release-notes/1.7#revprop-packing">http://subversion.apache.org/docs/release-notes/1.7#revprop-packing</a>
</pre>
<p>We reiterate that this lack of upgrade path is within the latitude of
our <a href="http://subversion.apache.org/prerelease-caveats">policy for pre-releases</a>. We may
provide in the future a script to downgrade a repository in-place to the
format supported by both 1.6 and 1.7. (We will welcome <a href="http://subversion.apache.org/contributing">contributions</a> of such a script.)</p>
<p>We plan to reintroduce revprop packing in a future release; see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3944">issue #3944</a> for details.</p>
</div> <!-- revprop-packing -->
<div class="h4" id="immediate-dir-removal">
<h4>'svn remove' now removes directories from disk immediately
<a class="sectionlink" href="#immediate-dir-removal" title="Link to this section">¶</a>
</h4>
<p>The <tt>svn remove</tt> command now removes directories from disk
immmediately. In Subversion 1.6, directories were scheduled for deletion
but kept on disk to retain meta-data stored in the <tt>.svn</tt> subdirectory.
With the new working copy format introduced in Subversion 1.7 it is no
longer necessary to keep the removed directory on disk. This also
facilitates better handling of directory replacements in the working
copy (see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3468">issue #3468</a> for details).</p>
<p>If the <tt>--keep-local</tt> option is used, <tt>svn remove</tt> will
keep the removed directory on disk.</p><p>
</p></div> <!-- immediate-dir-removal -->
</div> <!-- compat-misc -->
</div> <!-- compatibility -->
<div class="h2" id="new-features">
<h2>New Features
<a class="sectionlink" href="#new-features" title="Link to this section">¶</a>
</h2>
<div class="h3" id="wc-ng">
<h3>Working Copy Metadata Storage Improvements (<em>client</em>)
<a class="sectionlink" href="#wc-ng" title="Link to this section">¶</a>
</h3>
<p>Subversion 1.7 features a complete re-write of the working copy
metadata management system of Subversion, code named WC-NG. The old system
was one of the first parts of Subversion written, and over time had grown
difficult to maintain and extend. WC-NG is intended to provide an
immediate performance improvement, while also enabling many future feature
enhancements.</p>
<p>Although Subversion 1.7 does not introduce these new features, the
improvements in the working copy storage make them much more likely to
appear in future releases.</p>
<p>A number of known (and unknown) bugs have been fixed by the new working
copy metadata system (see
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3357">issue
#3357</a>).</p>
<div class="h4" id="single-db">
<h4>Centralized Metadata Storage
<a class="sectionlink" href="#single-db" title="Link to this section">¶</a>
</h4>
<p>A key feature of the changes introduced in Subversion 1.7 is the
centralization of working copy metadata storage into a single location.
Instead of a <tt>.svn</tt> directory in every directory in the working
copy, Subversion 1.7 working copies have just one <tt>.svn</tt>
directory—in the root of the working copy. This directory includes
(among other things) an SQLite-backed database which contains all of the
metadata Subversion needs for that working copy.</p>
<p>Even though the data is stored in a structured format, the relationships
between the data are complex. We highly discourage external tools from
modifying the data held in this database, as such modification is likely to
result in working copy corruption.</p>
<p></p>
<div class="notice"><span style="color: red"><b>WARNING:</b></span> It is not
safe to copy an SQLite file while it's being accessed via the SQLite
libraries. Consequently, duplicating a working copy (using <tt>tar</tt>,
<tt>cp</tt>, or <tt>rsync</tt>) that is being accessed by a Subversion
process is not supported for Subversion 1.7 working copies, and may
cause the duplicate (new) working copy to be created corrupted. (See <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3596">issue #3596</a> for details.)</div>
</div> <!-- single-db -->
<div class="h4" id="wc-pristines">
<h4>Pristine Contents
<a class="sectionlink" href="#wc-pristines" title="Link to this section">¶</a>
</h4>
<p>Subversion keeps a record of the unmodified contents of all files in the
working copy. Historically, these have been called <em>text-bases</em>, but
in Subversion 1.7, they have received a new name, and a new home. With the
centralization of metadata, the text-bases have been renamed
<em>pristines</em>, and are now located in the same <tt>.svn</tt>
directory as the working copy metadata.</p>
<p>The pristines are stored by checksum in a sharded format. Any files
in the working copy which have the same pristine content will now share
references to the pristine store, making such working copies slightly
smaller. Running <tt>svn cleanup</tt> will remove any pristines which
are no longer needed by the current state of the working copy.</p>
<p><strong>Note:</strong> In 1.7, we recommend to run <tt>svn cleanup</tt>
periodically in order to claim
back the disk space of unreferenced pristines. We expect a future Subversion
release to purge unreferenced (and thus unused) pristines automatically; see
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=4071">issue #4071</a>
for details.</p>
</div> <!-- wc-pristines -->
<div class="h4" id="wc-upgrade">
<h4>Upgrading the Working Copy
<a class="sectionlink" href="#wc-upgrade" title="Link to this section">¶</a>
</h4>
<p>Subversion 1.7 introduces substantial changes to the working copy format.
In previous releases of Subversion, Subversion would automatically update
the working copy to the new format when a write operation was performed.
Subversion 1.7, however, will make this a manual step. Before using
Subversion 1.7 with their working copies, users will be required
to run a new command, <tt>svn upgrade</tt> to update the metadata to the
new format. This command may take a while, and for some users, it may be more
practical to simply checkout a new working copy.</p>
<p><strong>Note:</strong> Subversion 1.7 cannot upgrade working copies that
a 1.6 client would have refused to operate upon before an <tt>svn cleanup</tt>
was run (with a 1.6 client). In other words, before upgrading to 1.7, a 1.6
client must be used to run <tt>svn cleanup</tt> on all working copies that
require cleanup. Likewise, Subversion 1.7 cannot upgrade corrupt 1.6 working
copies. Unfixable problems can arise from missing or corrupt meta-data inside
<tt>.svn</tt> directories. Such damage to the 1.6 working copy is permanent,
and cannot be fixed even if <tt>svn cleanup</tt> is run prior to the upgrade.</p>
<p>We regret these limitations, but we had to introduce them in order for
1.7 to ship timely and without overcomplicating the internals.
If your working copy does not upgrade cleanly, please check out a new one.</p>
<!-- 'sed -ne 5p < .svn/entries' to print `svn info | grep URL` of a 1.4-1.6 working copy. -->
</div> <!-- wc-upgrade -->
</div> <!-- wc-ng -->
<div class="h3" id="httpv2">
<h3>Improved HTTP protocol usage (<em>client</em> and <em>server</em>)
<a class="sectionlink" href="#httpv2" title="Link to this section">¶</a>
</h3>
<p>Over the years, many people have complained about the performance issues
with Subversion's use of HTTP as a repository access mechanism. This largely
stems from the developers' original intent to implement as much of the WebDAV
<a href="http://www.webdav.org/deltav/">DeltaV</a> specification as
possible. Alas, this specification was not widely implemented, so
none of the supposed benefits of the DeltaV overhead ever
materialized.</p>
<p>Subversion 1.7 offers a simpler HTTP protocol variant that can be used when
connecting to supported servers. This simpler protocol (sometimes referred to
as <em>HTTPv2</em>) requires fewer client-server round trips to establish a
connection, making Subversion much more performant on high-latency network
connections. Subversion's Serf-based repository access library (which will
<a href="#serf">become the default</a> library for HTTP in Subversion 1.8) has received
all of the protocol changes scheduled for 1.7, affecting both commit and read
operations; the older Neon-based library has received the most important and
high-impact of these changes, too.</p>
<p>As mentioned in the <a href="#new-feature-compatibility-table">compatibility
table</a>, Subversion 1.7 will only use HTTPv2 when connecting with a 1.7 (or
greater) server, but will continue to use existing protocols when communicating
with earlier versions of Subversion. Likewise, older clients will only use the
old protocol when connecting to a Subversion server, regardless of version.</p>
</div> <!-- httpv2 -->
<div class="h3" id="svnrdump">
<h3>New remote dumpfile tool: <tt>svnrdump</tt> (<em>client</em>)
<a class="sectionlink" href="#svnrdump" title="Link to this section">¶</a>
</h3>
<p>Subversion 1.7 adds a new tool to the client's toolbox:
<tt>svnrdump</tt>. <tt>svnrdump</tt> replicates the functionality of
<tt>svnadmin dump</tt> and <tt>svnadmin load</tt>, but works on
remote repositories, instead of needing administrator (local filesystem) access
to the source or target repository.</p>
<div class="h4" id="svnrdump-race">
<h4><tt>svnrdump load</tt> race condition
<a class="sectionlink" href="#svnrdump-race" title="Link to this section">¶</a>
</h4>
<p>Note that <tt>svnrdump load</tt> can suffer from a race condition
in its locking algorithm when run against a 1.6 or earlier server.
The race condition is only applicable if multiple <tt>svnrdump load</tt>
processes may attempt to write concurrently to a single repository.
This is the same problem that the new <a href="#atomic-revprops">atomic revprop changes feature</a> fixes for
<tt>svnsync</tt> (see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3546">issue #3546</a>), and the same <a href="#atomic-revprops">server-side
workaround</a> is available.</p>
<p>Server administrators who would like to block their users
from committing via <tt>svnrdump load</tt> may do so by installing the
following <tt>pre-revprop-change</tt> script:</p>
<pre>#!/bin/sh
PROPNAME="$4"
if [ "$PROPNAME" = "svn:rdump-lock" ]; then
echo "'svnrdump load' disabled by the server administrator" >&2
exit 1
fi
exit 0
</pre>
<p>This hook script suffices to protect repositories from <em>accidental</em> use
of <tt>svnrdump load</tt>. It does not (and cannot) protect the server from
users who intentionally recompile <tt>svnrdump</tt> in order to bypass this
restriction.</p>
</div> <!-- svnrdump-race -->
<div class="h4" id="svnrdump-editor">
<h4><tt>svnrdump dump</tt> and <tt>libsvn_ra_serf</tt> editor driving don't mix
<a class="sectionlink" href="#svnrdump-editor" title="Link to this section">¶</a>
</h4>
<p>The <tt>svnrdump dump</tt> command is more strict in its expectations
from the network access library than
<a href="http://subversion.apache.org/docs/api/latest/svn__ra_8h.html?svn_ra_replay_range#a9fbcde06ba0b9ddb331631852f3277bd">the API</a> permits it to be. This problem manifests itself in particular
with the <a href="#serf">ra_serf HTTP access library</a>, as documented
in <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=4116">issue #4116</a>. A workaround is to
<a href="http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html#svn.advanced.confarea.opts.servers">use the ra_neon HTTP access library</a> (which is the default).</p>
<p>The problem does not affect other executables (such as <tt>svn</tt> and
<tt>svnadmin</tt>). It also does not affect <tt>svnrdump</tt> when the default
HTTP access library, ra_neon, is used. Third-party API consumers should not
expect to be able to use all the orderings permitted by the
<a href="http://subversion.apache.org/docs/api/latest/structsvn__delta__editor__t.html">delta editor API</a>
when the editor receiver is <tt>svnrdump dump</tt>.</p>
<p>This problem is related to, but not the same as,
<a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.7/ra001.txt">ra_serf's dishonouring of the delta editor ordering rules</a>.</p>
</div> <!-- svnrdump-editor -->
</div> <!-- svnrdump -->
<div class="h3" id="patch">
<h3>New feature: <tt>svn patch</tt> (<em>client</em>)
<a class="sectionlink" href="#patch" title="Link to this section">¶</a>
</h3>
<p>Subversion 1.7 features a new subcommand called <tt>svn patch</tt>
which can apply patch files in unidiff format (as produced by
<tt>svn diff</tt> and other diff tools) to a working copy.</p>
<p><tt>svn patch</tt> will apply unidiff changes to existing files just
like third party patch tools.
It will also add newly created files to version control, and delete files
and directories which are left empty after patching.
Keywords and newlines are also handled automatically if the
<tt>svn:keywords</tt> and <tt>svn:eol-style</tt> properties are
set on patched files.</p>
<p><tt>svn diff</tt> will now produce unidiff output for Subversion
property changes, and <tt>svn patch</tt> is able to apply these changes
to properties (except for <tt>svn:mergeinfo</tt>, see
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3747">issue #3747</a>).</p>
<p>When a patch does not apply cleanly some or all changes listed in the
patch might be rejected. But <tt>svn patch</tt> currently does not
mark files with rejected changes as conflicted (see
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3565">issue #3565</a>). Files which weren't patched successfully can be
committed without being touched by <tt>svn resolve</tt> first.
This problem will be addressed in a future release of Subversion.</p>
<p>A new API for parsing unidiff patch files has been added to
<code>libsvn_diff</code>. A new API for applying unidiff patches to a
working copy has been added to <code>libsvn_client</code>.</p>
</div> <!-- patch -->
</div> <!-- new-features -->
<div class="h2" id="enhancements">
<h2>Enhancements and Bugfixes
<a class="sectionlink" href="#enhancements" title="Link to this section">¶</a>
</h2>
<!-- Don't need to highlight every bugfix, just major ones which aren't in
any patch release. -->
<div class="h3" id="cmdline">
<h3>Command-line client improvements (<em>client</em>)
<a class="sectionlink" href="#cmdline" title="Link to this section">¶</a>
</h3>
<p>There are far too many enhancements and new options to the
command-line client to list them all here. Aside from all the ones
mentioned already in these release notes, below are a few more that we
consider important, but please see the 1.7.0 section in the <a href="http://svn.apache.org/repos/asf/subversion/trunk/CHANGES">CHANGES</a> file
for a complete list.</p>
<!-- Insert selected items here -->
<div class="h4" id="log-diff">
<h4>svn log can now print diffs
<a class="sectionlink" href="#log-diff" title="Link to this section">¶</a>
</h4>
<p><tt>svn log</tt> accepts the new <strong><tt>--diff</tt></strong>
option which causes it to show changes committed in a revision as
a unified diff. Below is example output:</p>
<pre> $ svn log --diff -r1033146 http://svn.apache.org/repos/asf/subversion/trunk
------------------------------------------------------------------------
r1033146 | hwright | 2010-11-09 19:40:46 +0100 (Tue, 09 Nov 2010) | 3 lines
* subversion/libsvn_wc/wc_db.c
(svn_wc__db_op_copy): Remove unused variable.
Index: subversion/libsvn_wc/wc_db.c
===================================================================
--- subversion/libsvn_wc/wc_db.c (revision 1033145)
+++ subversion/libsvn_wc/wc_db.c (revision 1033146)
@@ -3061,7 +3061,7 @@ svn_wc__db_op_copy(svn_wc__db_t *db,
apr_pool_t *scratch_pool)
{
svn_wc__db_pdh_t *src_pdh, *dst_pdh;
- const char *src_relpath, *dst_relpath, *dst_op_root_relpath;
+ const char *src_relpath, *dst_relpath;
apr_int64_t dst_op_depth;
SVN_ERR_ASSERT(svn_dirent_is_absolute(src_abspath));
------------------------------------------------------------------------
</pre>
</div> <!-- log-diff -->
<div class="h4" id="update-parents">
<h4>svn update now accepts the --parents option
<a class="sectionlink" href="#update-parents" title="Link to this section">¶</a>
</h4>
<p><tt>svn update</tt> now accepts the <strong><tt>--parents</tt></strong>
option. This option removes the need to manually create missing parent
directories when adding additional items to a sparse working copy.</p>
<p>For example, adding 3 files from different directories to a sparse
working copy required creating each file's parent directories first:</p>
<pre> $ svn co --depth=empty ${PROJECT_ROOT_URL} wc
$ svn up --depth=empty wc/A wc/A/D wc/A/D/G wc/A/D/H wc/A/B wc/A/B/E
$ svn up wc/A/D/G/pi wc/A/D/H/omega wc/A/B/E/alpha
</pre>
<p>This becomes much easier with the new --parents option:</p>
<pre> $ svn co --depth=empty ${PROJECT_ROOT_URL} wc
$ svn up --parents wc/A/D/G/pi wc/A/D/H/omega wc/A/B/E/alpha
</pre>
</div> <!-- update-parents -->
<div class="h4" id="svn-relocate">
<h4>New subcommand: svn relocate
<a class="sectionlink" href="#svn-relocate" title="Link to this section">¶</a>
</h4>
<p>A new <tt>svn relocate</tt> subcommand has been added.
It points a working copy to a different repository root URL, serving
the same purpose as the old <tt>svn switch --relocate</tt> syntax
which has now been deprecated.
</p></div> <!-- svn-relocate -->
<div class="h4" id="switch-ancestry-check">
<h4>svn switch now checks ancestry
<a class="sectionlink" href="#switch-ancestry-check" title="Link to this section">¶</a>
</h4>
<p><tt>svn switch</tt> now checks that the working copy item being
switched shares common version control history with the URL to which
it is being switched.</p>
<p>This change was made to protect users from the unpleasant side
effects of oft-mistyped switch commands, such as accidentally
running <tt>svn switch ^/branches</tt> when you instead meant to
run <tt>svn switch ^/branches/<em>SOME-BRANCH</em></tt>. As of
version 1.7, Subversion will check to see if the source URL and the
target working copy item are ancestrally related and, if they do not,
the switch operation will fail with an error.</p>
<pre> $ svn switch ^/branches
svn: E195012: Path '.' does not share common version control ancestry
with the requested switch location. Use --ignore-ancestry to disable
this check.
$
</pre>
<p>What is meant by "ancestrally related"? In short, it means that if
you were to compare all the paths and revisions that each of these two
version controlled items has occupied over time — its current
repository location plus all previous ones, back through all the
copies and moves in its history — those two sets would
overlap.</p>
<p>As noted in the previous example's error message, this ancestry
check — which does come at some performance cost — may be
disabled by passing the <strong><tt>--ignore-ancestry</tt></strong>
option to the <tt>svn switch</tt> command.</p>
</div> <!-- switch-ancestry-check -->
<div class="h4" id="diff-show-copies-as-adds">
<h4>svn diff can show copied files as if they were newly added
<a class="sectionlink" href="#diff-show-copies-as-adds" title="Link to this section">¶</a>
</h4>
<p>When <tt>svn diff</tt> shows a copied file, it usually shows how the
copied file differs from the file it was copied from.
Sometimes this isn't the desired form of output. There are situations where
a copied file needs to appear in its entirety, for instance when producing
a patch file to be applied elsewhere with a patch tool (such as
<a href="#patch"><tt>svn patch</tt></a>).</p>
<p>In Subversion 1.7, <tt>svn diff</tt> takes a new
<strong><tt>--show-copies-as-adds</tt></strong> option which causes copied
files to be shown in their entirety, just like newly added files are shown.</p>
</div> <!-- diff-show-copies-as-adds -->
<div class="h4" id="diff-git">
<h4>svn diff can show git-style diff annotations
<a class="sectionlink" href="#diff-git" title="Link to this section">¶</a>
</h4>
<p><tt>svn diff</tt> takes a new
<strong><tt>--git</tt></strong> option which causes it to produce extra
annotations denoting added, deleted, and copied files.
This extended diff format was inspired by
<a href="http://www.kernel.org/pub/software/scm/git/docs/git-diff.html">git-diff</a>.</p>
<p><tt>svn diff --git</tt> is intended to produce patches which are
compatible to
<a href="http://www.kernel.org/pub/software/scm/git/docs/git-apply.html">git-apply</a>, but there are limitations due to differences between
Subversion and git:
</p><ul>
<li><tt>svn diff</tt> currently cannot display rename information.
Renames are always shown as a copy and a delete.</li>
<li>All paths in patches are shown relative to the repository root to
avoid ambiguity. It is possible that the numbers of leading path
components on the left and right side of the patch differ,
for instance if a diff between <tt>/trunk</tt> and
<tt>/branches/mybranch</tt> is shown.
This may prevent git-apply from applying such patches without
modification.</li>
</ul>
<p></p>
<p>In a future release of Subversion,
<a href="#patch"><tt>svn patch</tt></a> will receive support for the
extra annotations produced by <tt>svn diff --git</tt>, so that additions,
copies, renames, and deletions can be handled explicitly rather than
implicitly.</p>
<p>The same diff format extensions are also supported by
<a href="http://mercurial.selenic.com/">Mercurial</a>.</p>
</div> <!-- diff-git -->
<div class="h4" id="svn-help-merge">
<h4>svn merge help text has been enhanced
<a class="sectionlink" href="#svn-help-merge" title="Link to this section">¶</a>
</h4>
<p>The help text for the <tt>svn merge</tt> command has been enhanced.
It now explains common use cases and includes small examples, making it
more useful for quick reference.
</p></div> <!-- svn-help-merge -->
<div class="h4" id="svnlook-filesize">
<h4>New subcommand: svnlook filesize
<a class="sectionlink" href="#svnlook-filesize" title="Link to this section">¶</a>
</h4>
<p>A new <tt>svnlook filesize</tt> subcommand has been added.
It returns the size of a given path in the repository, for
a given revision or transaction. This is a constant-time operation
regardless of the size of the file. In pre-commit hooks wanting to
block commits with too large files, <tt>svnlook filesize</tt> can now
be used instead of the much more costly workaround via
<tt>svnlook cat</tt>.</p>
</div> <!-- svnlook-filesize -->
</div> <!-- cmdline -->
<div class="h3" id="apis">
<h3>API changes, improvements and language bindings
(<em>client and server</em>)
<a class="sectionlink" href="#apis" title="Link to this section">¶</a>
</h3>
<p>There are too many new and revised APIs in Subversion 1.7.0 to list
them all here. See the <a href="http://subversion.apache.org/docs/api/1.7/">Subversion API
Documentation</a> page for general API information. If you develop a
3rd-party client application that uses Subversion APIs, you should
probably look at the header files for the interfaces you use and see
what's changed.</p>
<p>As noted <a href="#compatibility">above</a>, a small number of APIs in
<code>libsvn_wc</code> have slightly changed functionality from their
historical roots. Each of these cases has been documented as an
<a href="http://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.7/">errata</a>,
detailing the impact of these changes. All of the errata were the result of
behavior which was deemed buggy, and the API changes are an attempt to fix
these bugs. The circumstances under which each is triggered are relatively
rare, and we anticipate the actual impact to end users will be minimal.</p>
<p>Language bindings have mostly been updated for the new APIs, though
some may lag more than others.</p>
<div class="h4" id="javahl">
<h4>JavaHL Updates
<a class="sectionlink" href="#javahl" title="Link to this section">¶</a>
</h4>
<p>Due to the move to the Apache Software Foundation, the JavaHL bindings
have been similarly moved to a new package: <code>org.apache.subversion</code>.
The old package still exists, and will continue to ship for backward
compatibility reasons, but we recommend comsumers switch to the new package,
as only it will continue to be updated.</p>
<p>Also, JavaHL now requires Java 1.5 to compile. In addition, many of the APIs
in the new package have been switch to use generics, and other Java 1.5
language features.</p>
</div> <!-- javahl -->
</div> <!-- apis -->
<div class="h3" id="bug-fixes">
<h3>Bug fixes (<em>client and server</em>)
<a class="sectionlink" href="#bug-fixes" title="Link to this section">¶</a>
</h3>
<p>A great many bugs have been fixed. See the 1.7.0 section in the <a href="http://svn.apache.org/repos/asf/subversion/trunk/CHANGES">CHANGES</a> file
for details.</p>
</div> <!-- bug-fixes -->
<div class="h3" id="serf">
<h3>Serf HTTP library improved and stabilized (<em>client</em>)
<a class="sectionlink" href="#serf" title="Link to this section">¶</a>
</h3>
<p>The <code>libsvn_ra_serf</code> repository access library has received
a lot of improvements and stabilization.
The design of <a href="http://code.google.com/p/serf/">serf</a> facilitates
future performance improvements that are impossible to achieve with
<a href="http://www.webdav.org/neon/">neon</a>. There were plans to make
serf the default HTTP access library for the 1.7 release.
But because of some remaining issues (for instance
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3979">issue #3979</a>,
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3980">issue #3980</a>, and
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3981">issue #3981</a>),
Subversion 1.7 still uses neon by default.
Remaining problems are mostly due to insufficient infrastructure deployed
in the wild wild web, such as HTTP proxies that do not support HTTP/1.1.
Workarounds for these problems will be implemented for the next release.
serf will become the default HTTP access library in Subversion 1.8.
</p>
<p>
In the meantime, we encourage all users to try serf with Subversion 1.7 and
<a href="http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs">report any problems</a>. Successful test reports are appreciated as well.
Tests in networks that use HTTP proxies or enterprise authentication are
particularly helpful.
You can configure which library the client should use on a default or
host-by-host basis by setting the <tt>http-library</tt> variable in the
client-side <tt>servers</tt> configuration file
(<tt>~/.subversion/servers</tt>).</p>
<div class="notice">
<p>Note that
<a href="http://svn.haxx.se/dev/archive-2011-01/0320.shtml">server-side configuration changes</a> might be required to avoid
performance regressions for serf clients in some setups.</p>
<p>The <strong>MaxKeepAliveRequests</strong> option in <tt>httpd.conf</tt>
needs to be increased from 100 (the default) to <b>at least</b> 1000
(there is no reason why it could not be 10000).
This will improve performance by allowing serf clients to use fewer
TCP connections to the server.
Clients using neon will also work fine with this configuration.</p>
</div>
<p>Because serf clients issue a larger number of HTTP GET requests
than neon clients it is possible that serf clients cause quicker
growth of httpd server logs than neon clients do. As of 1.7.3,
the httpd error logs may also grow more rapidly with serf clients
than with neon clients; see
<a href="http://svn.apache.org/viewvc?rev=1239697&view=rev">r1239697</a>.</p>
<p>Known issues with svnrdump that manifest when the latter uses
the ra_serf library for HTTP access are <a href="#svnrdump">documented under the 'svnrdump' section</a> of this document.</p>
</div> <!-- serf -->
<div class="h3" id="http-redirects">
<h3>Improved handling of HTTP redirects (<em>client</em>)
<a class="sectionlink" href="#http-redirects" title="Link to this section">¶</a>
</h3>
<p>In the past, when the Subversion client encountered an HTTP redirect
response from the server, it displayed an obtuse, and rarely-useful error
message. Subversion 1.7 improves the situation by following permanent
redirects (<tt>301 Moved Permanently</tt>) for <tt>svn update</tt> and <tt>svn
info</tt>, and providing a more useful error message on temporary
redirects (<tt>302 Found</tt> and <tt>307 Temporary Redirect</tt>).</p>
</div> <!-- http-redirects -->
<div class="h3" id="atomic-revprops">
<h3>Atomic revprop changes (<em>client</em> and <em>server</em>)
<a class="sectionlink" href="#atomic-revprops" title="Link to this section">¶</a>
</h3>
<p>Revprop changes are now handled atomically.
This fixes a known race condition in the locking algorithm used by
<tt>svnsync</tt> (see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3546">issue #3546</a>). It is possible to fix the svnsync race condition
even for pre-1.7 svnsync clients by installing the pre-revprop-change hook
script given in
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=3546#desc12">comment 12 of issue #3546</a>. (The hook script requires a 1.7 or newer
<em>server</em> for correctness.)</p>
</div> <!-- atomic-revprops -->
<div class="h3" id="merge-tracking-enhancements">
<h3>Merge-Tracking Enhancements
<a class="sectionlink" href="#merge-tracking-enhancements" title="Link to this section">¶</a>
</h3>
<p>While there are scores of bug fixes, performance improvements, and other
changes to merge-tracking, the following are the major changes. See the
1.7.0 section in the <a href="http://svn.apache.org/repos/asf/subversion/trunk/CHANGES">CHANGES</a>
file for a complete list.</p>
<div class="h4" id="subtree-mergeinfo-recording">
<h4>Reduced subtree mergeinfo changes
<a class="sectionlink" href="#subtree-mergeinfo-recording" title="Link to this section">¶</a>
</h4>
<p>Merges no longer record mergeinfo (describing the merge) on subtrees (that
have their own explicit mergeinfo), if the subtree was unaffected by the merge.
This should greatly reduce the number of spurious <tt>svn:mergeinfo</tt>
property changes for users who have large numbers of subtrees with explicit
mergeinfo.</p>
<p>If a change being merged contains svn:mergeinfo modifications these
will still be applied, just like any other property modifications.
So if the change being merged was itself the result of another merge
performed with a 1.5 or 1.6 client, excessive subtree mergeinfo changes
are still possible. Best results will be achieved for new branches
created and maintained exclusively with 1.7 clients.</p>
</div> <!-- subtree-mergeinfo-recording -->
<div class="h4" id="reintegrate-merges">
<h4>Reintegrate merges are less restrictive
<a class="sectionlink" href="#reintegrate-merges" title="Link to this section">¶</a>
</h4>
<p>Reintegrate merges now succeed in the case where all the prior 'sync'
merges were done as subtree merges, but effectively all the changes were
merged from the target to the source. Reintegrate also works with shallow
targets, as long as none of the excluded subtrees are affected by the
merge.</p>
</div> <!-- reintegrate-merges -->
<div class="h4" id="merge-notifications">
<h4>Improved notification about mergeinfo changes
<a class="sectionlink" href="#merge-notifications" title="Link to this section">¶</a>
</h4>
<p>Merge-tracking aware merges now produce special notifications and headers
when a merge records mergeinfo describing a merge or elides mergeinfo. This
clearly differentiates between changes that are made due to application of a
diff from the merge source and those that are simply merge-tracking
'housekeeping' changes.</p>
<p>Below is an example of the new output, showing notifications about
application of a diff to the file <tt>lib/src/psi.c</tt> and mergeinfo
changes resulting from this merge.</p>
<pre> $ svn merge ^/trunk -c3 --depth infinity
--- Merging r3 into 'lib':
U lib/src/psi.c
--- Recording mergeinfo for merge of r3 into '.':
U .
--- Recording mergeinfo for merge of r3 into 'lib':
G lib
--- Eliding mergeinfo from 'lib':
U lib
</pre>
</div> <!-- merge-notifications -->
<div class="h4" id="merge-mixed-rev-wc">
<h4>Merges into mixed-revision working copies now disallowed by default
<a class="sectionlink" href="#merge-mixed-rev-wc" title="Link to this section">¶</a>
</h4>
<p>To prevent unnecessary conflicts, <tt>svn merge</tt> will now fail
with an error if the merge target is a
<a href="http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs">mixed-revision working copy</a>.</p>
<p>A mixed-revision working copy will need to be updated with
<tt>svn update</tt> before a merge can be performed into it.
This restriction has always existed during merges using the
<strong><tt>--reintegrate</tt></strong> option and it is now the default
behaviour for every type of merge.</p>
<p>For backwards-compatibility, there is a new option called
<strong><tt>--allow-mixed-revisions</tt></strong> which disables the
check for a mixed-revision working copy, except for reintegrate merges.
Using this option is <strong>not</strong> recommended.
Please use <tt>svn update</tt> instead.</p>
</div> <!-- merge-mixed-rev-wc -->
<div class="h4" id="svn-mergeinfo-enhancements">
<h4>The mergeinfo subcommand accounts for subtree and partial merges
<a class="sectionlink" href="#svn-mergeinfo-enhancements" title="Link to this section">¶</a>
</h4>
<p>The <tt>svn mergeinfo</tt> subcommand now flags revisions wich are
partially merged to a target with the <tt>'*'</tt> decorator. A revision
may be partially merged due to non-inheritable mergeinfo on the target or
because of explicit mergeinfo on some subtree of the target. The latter case
is ignored by default, but may be considered by using the new <tt>--depth
</tt> and <tt>-R</tt> options for <tt>svn mergeinfo</tt>.</p>
</div> <!-- svn-mergeinfo-enhancements -->
<div class="h4" id="svn-merge-record-only">
<h4>Transitive record only merges
<a class="sectionlink" href="#svn-merge-record-only" title="Link to this section">¶</a>
</h4>
<p>Merges performed with the <tt>--record-only</tt> option now apply
<tt>svn:mergeinfo</tt> diffs from the merge source.</p>
</div> <!-- svn-merge-record-only -->
<div class="h4" id="svn-merge-sparse-no-tree-conflict">
<h4>Merges into sparse directories no longer cause tree conflicts
<a class="sectionlink" href="#svn-merge-sparse-no-tree-conflict" title="Link to this section">¶</a>
</h4>
<p>Merges into shallow working copies used to cause tree conflicts on nodes
which were affected by the merge but not present in the working copy.
In 1.7, no tree conflict is flagged. Instead, non-inheritable subtree mergeinfo
is created on the parents of missing nodes, so that later merges into working
copies that are not sparse will pick up any missing changes for those nodes.</p>
</div> <!-- svn-merge-sparse-no-tree-conflicts -->
</div> <!-- merge-tracking-enhancements -->
<div class="h3" id="server-performance-tuning">
<h3>Server-side performance tuning
<a class="sectionlink" href="#server-performance-tuning" title="Link to this section">¶</a>
</h3>
<p>Previous releases of Subversion already supported various caching
mechanism like memcached. In version 1.7, the servers will aggressively
cache data in-process to maximize performance. To mitigate the network
throughput as the next potential bottleneck in the chain, the data
compression rate can be configured as well.</p>
<div class="h4" id="data-caches">
<h4>Data caching
<a class="sectionlink" href="#data-caches" title="Link to this section">¶</a>
</h4>
<p>Per default, Subversion server processes will use a 16 MB memory
block to cache file and folder content. This amount is being allocated
by every server process, i.e., the maximum size of cache memory available
per process can roughly be estimated as</p>
<pre>cache limit = 0.8 * (RAM size / max. server process count) - 4 MB
</pre>
<p>A reasonable upper limit to that in-process cache size is the size
of the active data set. This is usually the size of user files in /trunk
plus the size of all differing files on active branches. So, two or
three times the sum of all /trunk sizes or all active projects on that
server is a reasonable indication for a performance-optimal cache size.
</p>
<p><tt>svnserve</tt> introduces a new optional <tt>--memory-cache-size</tt>
/ <tt>-M</tt> command line parameter to override the default cache
size. Using <tt>--cache-fulltexts</tt> and <tt>--cache-txdeltas</tt>
you may instruct the server what kind of data should be cached. The first
should always be enabled unless data is only read once as during a
<tt>svnrdump</tt> run. Text delta caching should be enabled unless
your server memory is low.</p>
<p>For <tt>mod_dav_svn</tt>, a 10 GB cache configuration with maximum
data coverage looks like this in <tt>httpd.conf</tt>
</p><pre><IfModule dav_svn_module>
SVNInMemoryCacheSize 10485760
SVNCacheFullTexts on
SVNCacheTextDeltas on
</IfModule>
</pre>
<p>As a side-effect, the memory consumption becomes more predictable
in many usage scenarios since there is less need to gather and pre-process
data. Please note that a cache size of <tt>0</tt> will deactivate the
new caching facilities and cause the server to fall back to 1.6 caching
mechanisms.</p>
</div> <!-- data-caches -->
<div class="h4" id="compression-level">
<h4>Network data compression level
<a class="sectionlink" href="#compression-level" title="Link to this section">¶</a>
</h4>
<p>Subversion servers are often disk or network I/O limited. With the
introduction of <a href="#data-caches">data caching</a>, however, disk
I/O can be widely eliminated and the CPU load created by data
compression will become a bottleneck on fast network connections.</p>
<p>The default setting will allow for 10 to 15 MB/s net data throughput
(5 MB to 10 MB compressed data) per client and per CPU core. On a
multi-core server with a 1 Gb network connection or if clients are mainly
connected with very limited bandwidth, you may want to select a higher
compression rate to squeeze a little more data through the network at
the expense of significantly higher server CPU loads. If the server's NIC
is not a bottleneck, you may consider lowering the compression level to
<tt>1</tt> or <tt>2</tt> for 100 Mb clients and to <tt>0</tt>
(compression off) for a network with predominately 1 Gb clients.</p>
<p>To that end, <tt>svnserve</tt> accepts the new optional
<tt>--compression</tt> or <tt>-c</tt> command line parameter.
<tt>mod_dav_svn</tt> supports the feature as well but its impact is
limited since over HTTP, network data compression is used only in certain
cases to begin with. The optional module parameter
<tt>SVNCompressionLevel</tt> controls it:</p>
<pre><IfModule dav_svn_module>
SVNCompressionLevel 9
</IfModule>
</pre>
</div> <!-- compression level -->
</div> <!-- server-performance-tuning -->
<div class="h3" id="diff-optimizations">
<h3>Optimizations of diff, merge and blame
<a class="sectionlink" href="#diff-optimizations" title="Link to this section">¶</a>
</h3>
<p>The svn diff algorithm, which is at the core of <tt>diff</tt>,
<tt>merge</tt> and <tt>blame</tt>, has undergone several optimizations.
For large files which have a lot of identical lines at the beginning
and/or the end, or files which have many lines which are unique to
one side of the comparison, the speedup can be very significant.</p>
</div> <!-- diff-optimizations -->
<div class="h3" id="libmagic-support">
<h3>Detecting MIME types with libmagic
<a class="sectionlink" href="#libmagic-support" title="Link to this section">¶</a>
</h3>
<p>Subversion 1.7 can optionally be compiled with support for
<a href="http://www.darwinsys.com/file/">libmagic</a> to detect
MIME types of binary files which are added to version control.
This feature is used only for binary files for which no MIME type
is found via auto-props or the mime-types-file configuration option.</p>
</div> <!-- libmagic-support -->
<div class="h3" id="windows-case-change">
<h3>Changing case of file and directory names on Windows
<a class="sectionlink" href="#windows-case-change" title="Link to this section">¶</a>
</h3>
<p>Subversion on Windows now fully supports changing the case of
file and directory names. No more special
<a href="http://subversion.apache.org/faq.html#case-change">workarounds</a>, a simple
'svn mv file.java File.java' just does the right thing.</p>
</div> <!-- windows-case-change -->
</div> <!-- enhancements -->
<div class="h2" id="issues">
<h2>Known issues in the release
<a class="sectionlink" href="#issues" title="Link to this section">¶</a>
</h2>
<p>There are some known issues in the Subversion 1.7.0 release. These
may be fixed in later 1.7.x releases.</p>
<div class="h3" id="rhel-2-issue">
<h3>64-bit RHEL2
<a class="sectionlink" href="#rhel-2-issue" title="Link to this section">¶</a>
</h3>
<p>Building Subversion 1.7.0 and APR 1.4.5 from source on 64-bit RHEL2
with the standard compiler will produce executables that SEGV on
startup. This problem is likely to affect all 64-bit x86 platforms
that use gcc 4.0.x or older and is due to APR bug
<a href="https://issues.apache.org/bugzilla/show_bug.cgi?id=51851">51851</a>.
Workarounds include using a more recent gcc or configuring APR
with <tt>--disable-nonportable-atomics</tt>.</p>
</div> <!-- rhel-2-issue -->
<div class="h3" id="osx-107-issue">
<h3>OS X 10.7
<a class="sectionlink" href="#osx-107-issue" title="Link to this section">¶</a>
</h3>
<p>The SQLite shipped with OS X 10.7 will produce executables that fail at
runtime with the error:</p>
<pre>svn: E200030: Could not initialize SQLite shared cache</pre>
<p>A fix for this problem will be included in the 1.7.1 release.</p>
</div> <!--osx-107-issue -->
<div class="h3" id="javahl-issue">
<h3>JavaHL SEGV during GC
<a class="sectionlink" href="#javahl-issue" title="Link to this section">¶</a>
</h3>
<p>The JavaHL bindings have moved to the org.apache.subversion package
with org.tigris.subversion provided as a compatibility layer. Using
the compatibility package will cause the JVM to SEGV when SVNAdmin or
SVNClient objects are finalized. A fix for this problem will be included
in the 1.7.1 release.</p>
</div> <!-- javahl-issue -->
<div class="h3" id="apr-146-issue">
<h3>APR 1.4.6
<a class="sectionlink" href="#apr-146-issue" title="Link to this section">¶</a>
</h3>
<p>When Subversion is built with APR 1.4.6 some of the Subversion
regression tests will FAIL at random due to a change in the APR hash
table implementation. The APR change causes some Subversion output to
appear in a different order and the testsuite will FAIL when it
expects the old order; the regression tests for the Subversion
bindings may also FAIL. This is a bug in the testsuite and does not
indicate a failure in Subversion. A fix for the main regression tests
will be included in the 1.7.4 release.</p>
</div> <!-- apr-146-issue -->
</div> <!-- issues -->
<div class="h2" id="distribution-changes">
<h2>Dependency, license and distribution changes
<a class="sectionlink" href="#distribution-changes" title="Link to this section">¶</a>
</h2>
<p>Subversion 1.7 marks the first official feature release as part of the
Apache Software Foundation. A few bits of minutiae have changed as a
result.</p>
<div class="h3" id="deps">
<h3>Subversion Dependency Distribution
<a class="sectionlink" href="#deps" title="Link to this section">¶</a>
</h3>
<p>Previous releases of Subversion shipped with companion artifacts which
included a number of Subversion dependencies. In the past, these dependencies
were hard to find and build, and not often installed on the target platform.
Today, this is no longer a problem, so we have discontinued shipping the
companion dependency tarballs. If you still want to get some of the required
Subversion dependencies before building, you can run the
<tt>get-deps.sh</tt> script in the root of the unpacked archive.</p>
</div> <!-- deps -->
<div class="h3" id="license">
<h3>License changed to Apache License, version 2
<a class="sectionlink" href="#license" title="Link to this section">¶</a>
</h3>
<p>Since its inception, Subversion has a used a "modified Apache license".
The migration of the project to the Apache Software Foundation provided
an opprotunity to also change the license to the standard
<a href="http://www.apache.org/licenses/LICENSE-2.0.html">Apache License,
version 2.</a> Additionally, the copyright to the collective work is now
owned by the ASF. While this has very little practical effect, it does mean
consumers have one less license to worry about when deploying Subversion.</p>
</div> <!-- license -->
<div class="h3" id="asf-mirrors">
<h3>Download location changes
<a class="sectionlink" href="#asf-mirrors" title="Link to this section">¶</a>
</h3>
<p>The download location for Subversion <a href="http://subversion.apache.org/download">source tarballs</a>
and <a href="http://subversion.apache.org/packages">other release artifacts</a>
are now hosted by the Apache Software Foundation. This includes the official
distribution location, as well as
<a href="http://archive.apache.org/dist/subversion/">archives</a> of all
previous Subversion releases. Of course, other locations are welcome to
continue to host Subversion distribution artifacts, but the Apache download
sites are now the canonical source for Subversion releases.</p>
</div> <!-- asf-mirrors -->
<div class="h3" id="contrib">
<h3>No longer shipping <tt>contrib/</tt>
<a class="sectionlink" href="#contrib" title="Link to this section">¶</a>
</h3>
<p>Since the early days of Subversion development, the Subversion repository
has hosted a section for various other tools and scripts related to
Subversion. As Subversion has become more popular, the need to host these
tools in the main repository has decreased to the point where we encourage
tool authors to host their contributions at one of a number of external
hosting platforms. For this reason, and the potentially uncertain nature of
some of the licenses on these scripts, we have stopped shipping the
<tt>contrib/</tt> directory in the release tarballs. For the time being,
these scripts remain available via the
<a href="http://svn.apache.org/repos/asf/subversion/trunk/contrib/">main
repository</a>.</p>
</div> <!-- contrib -->
</div> <!-- distribution-changes -->
<div class="h2" id="svn-1.5-deprecation">
<h2>Subversion 1.5.x series no longer supported
<a class="sectionlink" href="#svn-1.5-deprecation" title="Link to this section">¶</a>
</h2>
<p>The Subversion 1.5.x line is no longer supported. This doesn't
mean that your 1.5 installation is doomed; if it works well and is all
you need, that's fine. "No longer supported" just means we've stopped
accepting bug reports against 1.5.x versions, and will not make any
more 1.5.x bugfix releases.</p>
</div> <!-- svn-1.5-deprecation -->
<!-- ***************** END CONTENT ****************** -->
</div> <!-- #site-content -->
</body></html>
|