Copyright © 2011 The Apache + Software Foundation, Licensed under + the Apache + License, Version 2.0. 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.
+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 +(svnbook.red-bean.com).
+ +This page describes only major changes. For a complete list of +changes, see the 1.7 section of the CHANGES +file.
+ +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.
+ +There is no need 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.
+ +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.
+ +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 below for details).
+ +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.
+ +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
+API errata 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 libsvn_wc, with one notable
+exception: libsvn_ra_serf's approach to driving
+the svn_delta_editor_t interfaces (provided to it indirectly
+via calls to the svn_ra.h interfaces).
| New Feature | +Minimum Client1 | +Minimum Server | +Minimum Repository | +Notes |
|---|---|---|---|---|
| HTTPv2 | +1.7 | +1.7 | +any | +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 serf. |
| WC-NG | +1.7 | +any | +any | +1.6 working copies cannot be used with 1.7 and will + not be upgraded to the new 1.7 format + automatically. |
| svnrdump | +1.7 | +1.4 (dump) 1.7 (load) |
+ any | +See the full entry, below for discussion + of known issues. |
| svn patch | +1.7 | +any | +any | +|
| atomic revprop changes | +1.7 | +1.7 | +any | +Fixes a race condition in svnsync (issue #3546). |
| reduced subtree mergeinfo + recording | +1.7 | +any | +any | +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. |
| server performance tuning | +any | +1.7 | +any | +Purely server-side configuration. file:// access in 1.7 clients will + use the default settings. |
| 1Reminder: when using the file:// + repository access method, the Subversion program is both the client + and the server. | ||||
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 --xml option, +or accessing Subversion through the various bindings interfaces.
+ + + +Improvements have been made to the output of svn update +when updating multiple working copies at once (see +issue #3693). Below is an example of the new output:
+ +$ 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 ++ +
svn diff now shows textual property changes in unidiff format, +except for svn:mergeinfo properties. +Below is an example of the new output:
+ +$ 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 ++ +
The output of svn now contains an error number or warning +number with every error. The following example illustrates these changes.
+ +% svn info + svn: E155007: '/home/CIA-91' is not a working copy ++ +
These error values are useful as search keywords. Under the hood, these error +codes correspond to the API error codes 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 which-error.py script (first included in Subversion 1.3.0):
+ +% ./tools/dev/which-error.py 155007 + 00155007 SVN_ERR_WC_NOT_DIRECTORY ++ +
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.
+ +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 issue #3781).
+ +Subversion 1.6 introduced support for packing + FSFS revision files, 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 issue #3952 for the reason). Any +FSFS-backed repositories that were svnadmin created or +svnadmin upgraded by svnadmin from a nightly build or +from an alpha release of the 1.7.x line are not supported by +the final 1.7.0 release. It is required to dump these repositories +using an svnadmin built from the 1.7.0-alpha3 release (or to +svnsync them using a source server running 1.7.0-alpha3) in order to +upgrade them for the 1.7.0 release.
+ +Subversion 1.7 will complain when it encounters such repositories, with +the following error:
+ +subversion/libsvn_fs_fs/fs_fs.c:1083: (apr_err=160043) +svnadmin: E160043: Found format '5', only created by unreleased dev builds; + see http://subversion.apache.org/docs/release-notes/1.7#revprop-packing ++ +
We reiterate that this lack of upgrade path is within the latitude of +our policy for pre-releases. 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 contributions of such a script.)
+ +We plan to reintroduce revprop packing in a future release; see issue #3944 for details.
+ +The svn remove 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 .svn 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 issue #3468 for details).
+ +If the --keep-local option is used, svn remove will +keep the removed directory on disk.
+ +
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.
+ +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.
+ +A number of known (and unknown) bugs have been fixed by the new working +copy metadata system (see +issue +#3357).
+ +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 .svn directory in every directory in the working +copy, Subversion 1.7 working copies have just one .svn +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.
+ +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.
+ + + +Subversion keeps a record of the unmodified contents of all files in the +working copy. Historically, these have been called text-bases, 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 +pristines, and are now located in the same .svn +directory as the working copy metadata.
+ +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 svn cleanup will remove any pristines which +are no longer needed by the current state of the working copy.
+ +Note: In 1.7, we recommend to run svn cleanup +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 +issue #4071 +for details.
+ +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, svn upgrade 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.
+ +Note: Subversion 1.7 cannot upgrade working copies that +a 1.6 client would have refused to operate upon before an svn cleanup +was run (with a 1.6 client). In other words, before upgrading to 1.7, a 1.6 +client must be used to run svn cleanup 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 +.svn directories. Such damage to the 1.6 working copy is permanent, +and cannot be fixed even if svn cleanup is run prior to the upgrade.
+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.
+ + + +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 +DeltaV specification as +possible. Alas, this specification was not widely implemented, so +none of the supposed benefits of the DeltaV overhead ever +materialized.
+ +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 HTTPv2) 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 +become the default 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.
+ +As mentioned in the compatibility +table, 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.
+ +Subversion 1.7 adds a new tool to the client's toolbox: +svnrdump. svnrdump replicates the functionality of +svnadmin dump and svnadmin load, but works on +remote repositories, instead of needing administrator (local filesystem) access +to the source or target repository.
+ +Note that svnrdump load 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 svnrdump load +processes may attempt to write concurrently to a single repository. +This is the same problem that the new atomic revprop changes feature fixes for +svnsync (see issue #3546), and the same server-side +workaround is available.
+ +Server administrators who would like to block their users +from committing via svnrdump load may do so by installing the +following pre-revprop-change script:
+ +#!/bin/sh +PROPNAME="$4" +if [ "$PROPNAME" = "svn:rdump-lock" ]; then + echo "'svnrdump load' disabled by the server administrator" >&2 + exit 1 +fi +exit 0 ++ +
This hook script suffices to protect repositories from accidental use +of svnrdump load. It does not (and cannot) protect the server from +users who intentionally recompile svnrdump in order to bypass this +restriction.
+ +The svnrdump dump command is more strict in its expectations +from the network access library than +the API permits it to be. This problem manifests itself in particular +with the ra_serf HTTP access library, as documented +in issue #4116. A workaround is to +use the ra_neon HTTP access library (which is the default).
+ +The problem does not affect other executables (such as svn and +svnadmin). It also does not affect svnrdump 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 +delta editor API +when the editor receiver is svnrdump dump.
+ +This problem is related to, but not the same as, +ra_serf's dishonouring of the delta editor ordering rules.
+ +Subversion 1.7 features a new subcommand called svn patch +which can apply patch files in unidiff format (as produced by +svn diff and other diff tools) to a working copy.
+ +svn patch 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 +svn:keywords and svn:eol-style properties are +set on patched files.
+ +svn diff will now produce unidiff output for Subversion +property changes, and svn patch is able to apply these changes +to properties (except for svn:mergeinfo, see +issue #3747).
+ +When a patch does not apply cleanly some or all changes listed in the +patch might be rejected. But svn patch currently does not +mark files with rejected changes as conflicted (see +issue #3565). Files which weren't patched successfully can be +committed without being touched by svn resolve first. +This problem will be addressed in a future release of Subversion.
+ +A new API for parsing unidiff patch files has been added to
+libsvn_diff. A new API for applying unidiff patches to a
+working copy has been added to libsvn_client.
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 CHANGES file +for a complete list.
+ + + +svn log accepts the new --diff +option which causes it to show changes committed in a revision as +a unified diff. Below is example output:
+ $ 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));
+
+ ------------------------------------------------------------------------
+
+
+svn update now accepts the --parents +option. This option removes the need to manually create missing parent +directories when adding additional items to a sparse working copy.
+ +For example, adding 3 files from different directories to a sparse +working copy required creating each file's parent directories first:
+ $ 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
+
+This becomes much easier with the new --parents option:
+ $ 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
+
+A new svn relocate subcommand has been added. +It points a working copy to a different repository root URL, serving +the same purpose as the old svn switch --relocate syntax +which has now been deprecated. +
svn switch now checks that the working copy item being +switched shares common version control history with the URL to which +it is being switched.
+ +This change was made to protect users from the unpleasant side +effects of oft-mistyped switch commands, such as accidentally +running svn switch ^/branches when you instead meant to +run svn switch ^/branches/SOME-BRANCH. 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.
+ +$ 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. + $ ++ +
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.
+ +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 --ignore-ancestry +option to the svn switch command.
+When svn diff 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 +svn patch).
+ +In Subversion 1.7, svn diff takes a new +--show-copies-as-adds option which causes copied +files to be shown in their entirety, just like newly added files are shown.
+ +svn diff takes a new +--git option which causes it to produce extra +annotations denoting added, deleted, and copied files. +This extended diff format was inspired by +git-diff.
+ +svn diff --git is intended to produce patches which are +compatible to +git-apply, but there are limitations due to differences between +Subversion and git: +
In a future release of Subversion, +svn patch will receive support for the +extra annotations produced by svn diff --git, so that additions, +copies, renames, and deletions can be handled explicitly rather than +implicitly.
+ +The same diff format extensions are also supported by +Mercurial.
+ +The help text for the svn merge command has been enhanced. +It now explains common use cases and includes small examples, making it +more useful for quick reference. +
A new svnlook filesize 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, svnlook filesize can now +be used instead of the much more costly workaround via +svnlook cat.
+There are too many new and revised APIs in Subversion 1.7.0 to list +them all here. See the Subversion API +Documentation 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.
+ +As noted above, a small number of APIs in
+libsvn_wc have slightly changed functionality from their
+historical roots. Each of these cases has been documented as an
+errata,
+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.
Language bindings have mostly been updated for the new APIs, though +some may lag more than others.
+ +Due to the move to the Apache Software Foundation, the JavaHL bindings
+have been similarly moved to a new package: org.apache.subversion.
+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.
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.
+ +A great many bugs have been fixed. See the 1.7.0 section in the CHANGES file +for details.
+ +The libsvn_ra_serf repository access library has received
+a lot of improvements and stabilization.
+The design of serf facilitates
+future performance improvements that are impossible to achieve with
+neon. There were plans to make
+serf the default HTTP access library for the 1.7 release.
+But because of some remaining issues (for instance
+issue #3979,
+issue #3980, and
+issue #3981),
+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.
+
+In the meantime, we encourage all users to try serf with Subversion 1.7 and +report any problems. 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 http-library variable in the +client-side servers configuration file +(~/.subversion/servers).
+ +Note that +server-side configuration changes might be required to avoid +performance regressions for serf clients in some setups.
+The MaxKeepAliveRequests option in httpd.conf +needs to be increased from 100 (the default) to at least 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.
+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 +r1239697.
+ +Known issues with svnrdump that manifest when the latter uses +the ra_serf library for HTTP access are documented under the 'svnrdump' section of this document.
+ +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 (301 Moved Permanently) for svn update and svn +info, and providing a more useful error message on temporary +redirects (302 Found and 307 Temporary Redirect).
+ +Revprop changes are now handled atomically. +This fixes a known race condition in the locking algorithm used by +svnsync (see issue #3546). 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 +comment 12 of issue #3546. (The hook script requires a 1.7 or newer +server for correctness.)
+ +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 CHANGES +file for a complete list.
+ +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 svn:mergeinfo +property changes for users who have large numbers of subtrees with explicit +mergeinfo.
+ +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.
+ +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.
+ +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.
+ +Below is an example of the new output, showing notifications about +application of a diff to the file lib/src/psi.c and mergeinfo +changes resulting from this merge.
+ +$ 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 ++ +
To prevent unnecessary conflicts, svn merge will now fail +with an error if the merge target is a +mixed-revision working copy.
+ +A mixed-revision working copy will need to be updated with +svn update before a merge can be performed into it. +This restriction has always existed during merges using the +--reintegrate option and it is now the default +behaviour for every type of merge.
+ +For backwards-compatibility, there is a new option called +--allow-mixed-revisions which disables the +check for a mixed-revision working copy, except for reintegrate merges. +Using this option is not recommended. +Please use svn update instead.
+ +The svn mergeinfo subcommand now flags revisions wich are +partially merged to a target with the '*' 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 --depth + and -R options for svn mergeinfo.
+ +Merges performed with the --record-only option now apply +svn:mergeinfo diffs from the merge source.
+ +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.
+ +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.
+ +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
+ +cache limit = 0.8 * (RAM size / max. server process count) - 4 MB ++ +
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. +
+ +svnserve introduces a new optional --memory-cache-size +/ -M command line parameter to override the default cache +size. Using --cache-fulltexts and --cache-txdeltas +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 +svnrdump run. Text delta caching should be enabled unless +your server memory is low.
+ +For mod_dav_svn, a 10 GB cache configuration with maximum +data coverage looks like this in httpd.conf + +
<IfModule dav_svn_module> + SVNInMemoryCacheSize 10485760 + SVNCacheFullTexts on + SVNCacheTextDeltas on +</IfModule> ++ +
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 0 will deactivate the +new caching facilities and cause the server to fall back to 1.6 caching +mechanisms.
+ +Subversion servers are often disk or network I/O limited. With the +introduction of data caching, however, disk +I/O can be widely eliminated and the CPU load created by data +compression will become a bottleneck on fast network connections.
+ +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 +1 or 2 for 100 Mb clients and to 0 +(compression off) for a network with predominately 1 Gb clients.
+ +To that end, svnserve accepts the new optional +--compression or -c command line parameter. +mod_dav_svn 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 +SVNCompressionLevel controls it:
+ +<IfModule dav_svn_module> + SVNCompressionLevel 9 +</IfModule> ++ +
The svn diff algorithm, which is at the core of diff, +merge and blame, 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.
+ +Subversion 1.7 can optionally be compiled with support for +libmagic 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.
+ +Subversion on Windows now fully supports changing the case of +file and directory names. No more special +workarounds, a simple +'svn mv file.java File.java' just does the right thing.
+ +There are some known issues in the Subversion 1.7.0 release. These +may be fixed in later 1.7.x releases.
+ +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 +51851. +Workarounds include using a more recent gcc or configuring APR +with --disable-nonportable-atomics.
+ +The SQLite shipped with OS X 10.7 will produce executables that fail at +runtime with the error:
+svn: E200030: Could not initialize SQLite shared cache+
A fix for this problem will be included in the 1.7.1 release.
+ +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.
+ +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.
+ +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.
+ +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 +get-deps.sh script in the root of the unpacked archive.
+ +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 +Apache License, +version 2. 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.
+ +The download location for Subversion source tarballs +and other release artifacts +are now hosted by the Apache Software Foundation. This includes the official +distribution location, as well as +archives 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.
+ +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 +contrib/ directory in the release tarballs. For the time being, +these scripts remain available via the +main +repository.
+ +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.
+ +Copyright © 2011 The Apache + Software Foundation, Licensed under + the Apache + License, Version 2.0. 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.
+Apache Subversion 1.6 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.5.x is also +in 1.6, but 1.6 contains features and bugfixes not present in any +earlier release. The new features will eventually be documented in a +1.6 version of the free Subversion book +(svnbook.red-bean.com).
+ +This page describes only major changes. For a complete list of +changes, see the 1.6 section of the CHANGES +file.
+ +Older clients and servers interoperate transparently with 1.6 +servers and clients. However, some of the new 1.6 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.
+ +There is no need to dump and reload your +repositories. Subversion 1.6 can read repositories created by earlier +versions. To upgrade an existing installation, just install the +newest libraries and binaries on top of the older ones.
+ +Subversion 1.6 maintains API/ABI compatibility with earlier +releases, by only adding new functions, never removing old ones. A +program written to the 1.0, 1.1, 1.2, 1.3, 1.4 or 1.5 API can both compile +and run using 1.6 libraries. However, a program written for 1.6 +cannot necessarily compile or run against older libraries.
+ +| New Feature | +Minimum Client1 | +Minimum Server | +Minimum Repository | +Notes |
|---|---|---|---|---|
| FSFS Packing | +any | +1.6 | +1.6 | +|
| Tree Conflicts | +1.6 | +1.6 | +any | +Using servers older than 1.6 is possible, but some kinds + of conflicts will not be detected. |
1Reminder: when using the file://
+ repository access method, the Subversion program is both the client
+ and the server. | ||||
The working copy format has been upgraded. This means that 1.5 and +older Subversion clients will not be able to work with +working copies produced by Subversion 1.6. Working copies are upgraded automatically.
+ +Similarly, the repository filesystem formats have changed, meaning +that 1.5 and older versions of Subversion tools that normally access +a repository directly (e.g. svnserve, mod_dav_svn, +svnadmin) won't be able to read a repository created by +Subversion 1.6. But, repositories are not upgraded automatically.
+ +WARNING: if a Subversion 1.6 client encounters a +pre-1.6 working copy, it will automatically upgrade the +working copy format as soon as it touches it, making it unreadable by +older Subversion clients. If you are using several versions of +Subversion on your machine, be careful about which version you use in +which working copy, to avoid accidentally upgrading a working copy. +(But note that this "auto upgrade" behavior does not occur +with the repositories, only working +copies.)
+ +If you accidentally upgrade a 1.5 working copy to 1.6, and wish to
+downgrade back to 1.5, use the change-svn-wc-format.py script. See this FAQ entry for details, and run the script with the
+--help option for usage instructions.
The Subversion 1.6 server works with 1.5 and older repositories,
+and it will not upgrade such repositories to 1.6 unless
+specifically requested to via the
+svnadmin upgrade command. This means
+that some of the new 1.6 features will not become available simply by
+upgrading your server: you will also have to upgrade your
+repositories. (We decided not to auto-upgrade repositories because we
+didn't want 1.6 to silently make repositories unusable by
+1.5 — that step should be a conscious decision on the
+part of the repository admin.)
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.
+ +svn proplist --verbose
+ ¶
+The output of svn proplist --verbose has been
+improved, and svn propget now accepts the --verbose
+option. The following example illustrates these changes.
$ svn proplist --verbose build.conf + Properties on 'build.conf': + svn:eol-style + native + svn:mergeinfo + /trunk/build.conf:1-4800 + /branches/a/build.conf:3000-3400 + /branches/b/build.conf:3200-3600 + $ ++ +
svn status
+ ¶
+The output of svn status contains the additional seventh
+column which informs whether the item is the victim of a tree conflict.
+An additional line with more detailed description of a tree conflict is
+displayed after each item remaining in tree conflict.
$ svn status + M Makefile.in + A C src/error.c + > local add, incoming add upon update + M src/log.c + M C src/path.c + > local edit, incoming delete upon update + D C src/properties.c + > local delete, incoming edit upon merge + M C src/time.c + $ ++ +
svn update and
+ svn merge
+ ¶
+svn update and svn merge now print
+a summary of conflicts upon completion.
+
+$ svn update --accept=postpone + C alpha + C beta +C gamma +Updated to revision 3. +Summary of conflicts: + Text conflicts: 1 + Property conflicts: 1 + Tree conflicts: 1 ++ +Minor problems with the conflict summary are described in +issue 3342. + +
This section is currently incomplete, please +help write it! See the +design notes for more information.
+ +$ svn SUBCOMMAND ^/ + $ svn SUBCOMMAND ^/PATH ++ +
Subversion 1.6 adds a couple of new features for users of +svn:externals. The include:
+ + + ++ If the URL in a svn:externals description refers to a file, + it will be added into the working copy as a versioned item. +
+ ++ There are a few differences between directory and file + externals. +
+ +The differences between a normal versioned file and a file +external.
+ +Other facts.
+ +Need to document possible incompatibilities (see +this +thread)
+ +See The svn:externals section of the Subversion Book.
+ +Subversion 1.6 recognizes a new kind of conflict, known as a +"tree conflict". Such conflicts manifest at the level +of directory structure, rather than file content.
+ +Situations now flagged as conflicts include deletions of locally +modified files, and incoming edits to locally deleted files. Files +and directories which are victims of a tree conflict cannot be +committed before the conflict is marked resolved.
+ +Note that Subversion is still treating renames as a "copy+delete" +operation, so file renames causing tree conflicts can only be detected +in terms of file additions and deletions. Because of this, false positives +during tree conflict detection are possible.
+ +To facilitate tree conflict detection, attempting to commit the +deletion of a file which has already been deleted in the HEAD revision +now causes an error. In Subversion 1.5, this was treated as a no-op, +potentially resulting in "empty" revisions which contained +no changes.
+ + +See the tree conflicts section of the Subversion Book.
+ +Subversion 1.6 contains several improvements to both the Berkeley DB and FSFS +backends. These are designed to improve storage space, and can result in +drastically smaller repositories. These changes include:
+When using many branches and merging between them often, it is common to +have files with similar lines of history which contain the exact same content. +In the past, Subversion has stored these files as deltas against previous +versions of the file. Subversion 1.6 will now use existing representations in +the filesystem for duplicate storage. Depending on the size of the repository, +and the degree of branching and merging, this can cause an up to 20% space +reduction for Berkeley DB repositories and a 15% reduction for FSFS +repositories.
+ +Subversion 1.5 introduced the ability for FSFS repositories to be +sharded into +multiple directories for revision and revprop files. Subversion 1.6 takes +the sharding concept further, and allows full shard directories to be +packed into a single file. By reducing internal fragmentation in +the filesystem, packed FSFS repositories have significant space savings +over their unpacked counterparts, especially repositories which contain +many small commits. Using a one-file-per-shard approach also allows +Subversion to reduce disk I/O and better exploit operating system caches. +
+ +To pack a repository, run svnadmin pack on the repository.
+Once a repository has been packed, there is no migration path back to an
+unpacked state, and it can only be read by Subversion 1.6 or greater
+servers.
Memcached can +cache data of FSFS repositories.
+ +Additional build-time dependencies: APR-Util ≥1.3 || ( APR-Util < +1.3 && APR_Memcache )
+ +Newly created BDB repositories now use forward deltas instead of reverse
+deltas. svnadmin upgrade can be used to make older repositories
+use forward deltas for new revisions. If you want to achieve the most
+optimized state of an older repository, you still need to perform dump and
+load of the repository.
Subversion 1.6 introduces a new python binding for the Subversion API. The +new binding makes use of the ctypes library to present the standard API along +with a selection of Python classes to give an object-oriented interface to +standard Subversion constructs. These bindings have several advantages over +the traditional SWIG-based bindings:
+Building the ctypes bindings produces two ways to access Subversion from +python. The first interface is a direct python port of the standard API. +Ctypes provides some basic type conversions and allows the calling of +Subversion functions just like in C code. The new bindings also introduce a +set of python classes to enable higher-level access to Subversion features. +These classes take full advantage of python features and hide as much of the +C implementation as possible to make Subversion easier to use for python +programmers not familiar with the C API.
+ +Interactive conflict resolution supports new display-conflict,
+mine-conflict and theirs-conflict options.
Here's an example using the command-line client:
+ +$ svn up + U Makefile.in + Conflict discovered in 'configure.ac'. + Select: (p) postpone, (df) diff-full, (e) edit, + (mc) mine-conflict, (tc) theirs-conflict, + (s) show all options: s + + (e) edit - change merged file in an editor + (df) diff-full - show all changes made to merged file + (r) resolved - accept merged version of file + + (dc) display-conflict - show all conflicts (ignoring merged version) + (mc) mine-conflict - accept my version for all conflicts (same) + (tc) theirs-conflict - accept their version for all conflicts (same) + + (mf) mine-full - accept my version of entire file (even non-conflicts) + (tf) theirs-full - accept their version of entire file (same) + + (p) postpone - mark the conflict to be resolved later + (l) launch - launch external tool to resolve conflict + (s) show all - show this list + + Select: (p) postpone, (df) diff-full, (e) edit, + (mc) mine-conflict, (tc) theirs-conflict, + (s) show all options: mc + G configure.ac + Updated to revision 36666. + $ ++ +
In Subversion 1.6, the --set-depth parameter to svn
+update has grown a new value—exclude. This value tells
+Subversion to exclude the target from the working copy, immediately and until
+further notice. Prior to Subversion 1.6, if a directory could not easily be
+removed from a working copy. If it was deleted without the help of Subversion,
+it would return on the next svn update. If it was deleted with
+svn delete, the directory remained as a local modification
+forever. (Unless, of course, it was accidentally committed.) The new exclusion
+mechanism in Subversion 1.6 fixes both these problems.
Note that if you exclude a versioned directory that has some unversioned +files in it, or some files with local modifications, Subversion handles this +situation gracefully. All the files that aren't safe to delete, Subversion +leaves around, and of course leaves any intermediate directories required to +reach those files, too.
+ + + +svnserve now accepts the --log-file option which
+allows to specify the file used for logging.
mod_dav_svn now supports a new public URI syntax for +examining older versions of files or directories. The intent here is +to allow users to examine history without the use of an svn client, +and to make it easier for 3rd-party tools (e.g. code-review services) +to work directly against repositories without using svn libraries.
+ +http://host/repos/path?[p=PEG][&r=REV]+ +
The new syntax works similarly to the way URIs work with the svn + commandline client. Simply requesting http://host/repos/path + fetches "path" in the HEAD revision. Adding a "p" query argument + specifies a different peg revision instead, so that:
+ +http://host/repos/path?p=38+ +
...is similar to specifying "path@38" on the commandline. Adding a + "r" query argument is like specifying "-r" on the commandline, + causing the repository to follow history backwards from the peg + revision to the older operative revision:
+ +http://host/repos/path?p=38&r=20+ +
As with the commandline, the peg revision defaults to HEAD if + unspecified, and the operative revision defaults to the peg + revision. The online Subversion Book has + a section + explaining peg and operative revisions in great detail.
+ +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.6.0 section in the CHANGES file +for a complete list.
+ +The svn log command can now take multiple revision arguments
+in one invocation. Both the -c and -r arguments are supported.
$ svn log -r36169 -r36171 http://svn.collab.net/repos/svn/ + ------------------------------------------------------------------------ + r36169 | sussman | 2009-02-26 14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line + + ...log message omitted... + ------------------------------------------------------------------------ + r36171 | joeswatosh | 2009-02-26 22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines + + ...log message omitted... + $ svn log -c36169,36171 http://svn.collab.net/repos/svn/ + ------------------------------------------------------------------------ + r36169 | sussman | 2009-02-26 14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line + + ...log message omitted... + ------------------------------------------------------------------------ + r36171 | joeswatosh | 2009-02-26 22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines + + ...log message omitted... ++ +
Option added to svn and svnsync, so that
+non-interactive operations can work with self-signed certificates not
+backed by a known trust authority.
$ svn log -r36364 https://svn.collab.net/repos/svn/trunk --trust-server-cert --non-interactive + ------------------------------------------------------------------------ + r36364 | stylesen | 2009-03-06 13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines + + ...log message omitted... + ------------------------------------------------------------------------ ++ +without this option: +
$ svn log -r36364 https://svn.collab.net/repos/svn/trunk + Error validating server certificate for 'https://svn.collab.net': + - The certificate is not issued by a trusted authority. Use the + fingerprint to validate the certificate manually! + Certificate information: + - Hostname: svn.collab.net + - Valid: from Sep 24 22:01:07 2007 GMT until Sep 23 22:01:07 2011 GMT + - Issuer: sv, CollabNet, Brisbane, California, US + (hostname@collab.net) + - Fingerprint: + AA:5B:74:B1:E2:7F:38:B3:2B:C2:B1:60:6E:01:BB:F5:7C:37:98:46 + (R)eject, accept (t)emporarily or accept (p)ermanently? t + ------------------------------------------------------------------------ + r36364 | stylesen | 2009-03-06 13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines + + ...log message omitted... + ------------------------------------------------------------------------ ++ +
The pre-lock hook can now specify the lock-token string +via the hook's stdout; see r32778 for details. Note that when the hook uses this feature, +it must take responsibility for ensuring that lock tokens are unique +across the repository.
+ +There are too many new and revised APIs in Subversion 1.6.0 to list +them all here. See the Subversion API +Documentation 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.
+ +One general change is that most APIs that formerly took a +recurse parameter have been upgraded to accept a +depth parameter instead, to enable the new sparse checkouts feature.
+ +Language bindings have mostly been updated for the new APIs, though +some may lag more than others.
+ +The Subversion 1.4.x line is no longer supported. This doesn't +mean that your 1.4 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.4.x versions, and will not make any +more 1.4.x bugfix releases.
+ +We now require SQLite to build both
+the server and client. We recommend 3.6.13 or greater, but work with
+anything better than 3.4.0. Subversion will attempt to use an SQLite
+amalgamation if it is
+present in the root of the distribution tarball, otherwise, Subversion will
+search for SQLite in the usual places on the system. You may also pass
+--with-sqlite to configure to specify the location
+of the SQLite library or amalgamation you wish to use.