Note: Subversion 1.5 is not released yet. When it is released, this warning message will disappear, and the rest of this page will become the release notes. Until then, this page describes what is planned for the release.

Subversion 1.5 Release Notes

What's New in Subversion 1.5

Details are described below.

Subversion 1.5 is a superset of all previous Subversion releases, and is considered the current "best" release. Anything in 1.0.x through 1.4.x is also in 1.5, but 1.5 contains features and bugfixes not present in any earlier release. The new features will eventually be documented in a 1.5 version of the free Subversion book, see svnbook.red-bean.com.

Compatibility Concerns

Older clients and servers interoperate transparently with 1.5 servers and clients. Of course, some of the new 1.5 features may not be available unless both client and server are the latest version (e.g. Merge Tracking). There is no need to dump and reload your repositories; Subversion 1.5 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.5 maintains API/ABI compatibility with earlier releases, by only adding new functions. A program written to the 1.0, 1.1, 1.2 or 1.3 API can both compile and run using 1.5 libraries. However, a program written for 1.5 cannot necessarily compile or run against older libraries. However, see the API section on some clarifications on existing APIs.

Working Copy and Repository Format Changes

Due to certain improvements and bugfixes made to the working copy library, the version number of the working copy format has been incremented. This means that Subversion clients earlier than 1.5 will not be able to work with working copies produced by Subversion 1.5. Similarly, the repository format has changed as well, meaning that pre-1.5 Subversion tools that normally access a repository directly (e.g. svnserve, mod_dav_svn, svnadmin) won't be able to read a repository originally created by Subversion 1.5.

WARNING: if a Subversion 1.5 client encounters a pre-1.5 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, you need to be careful about which version you use in which working copy, to avoid accidentally upgrading the working copy format. This "auto upgrade" feature, however, does not occur with the new repository format.

If you do accidentally upgrade a 1.4 (only) working copy, you can use this script to downgrade it back 1.4. See the FAQ for details, and run the script with the --help option for usage instructions.

Command Line Output Changes

Although the Subversion developers try hard to keep output from the command line programs compatible between releases, new information sometimes has to be added. This might break scripts that rely on the exact format of the output. In 1.5, the following changes have been made to the output:

XXX: Enumerate changes to output (e.g. for changelists).

  • Conflict markers in files now match the file's defined eol-style.

New Features

XXX: Describe each new feature. See the 1.4 RNs for a "template".

Merge Tracking (client and server)

XXX

Sparse checkouts (client and server)

XXX: Described here.

Interactive Conflict Resolution (client)

Added support for interactive conflict resolution in the command line client, and a corresponding callback function in the client library. GUI clients can use the callback function to hook in a graphical conflict resolution program to the update/switch/merge sub-commands. Example command line output:

    $ svn up
    U    contrib/client-side/svnmerge/svnmerge_test.py
    Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
    Select: (p)ostpone, (d)iff, (e)dit, (h)elp : h
      (p)ostpone - mark the conflict to be resolved later
      (d)iff     - show all changes made to merged file
      (e)dit     - change merged file in an editor
      (r)esolved - accept merged version of file
      (m)ine     - accept my version of file
      (t)heirs   - accept repository's version of file
      (l)aunch   - use third-party tool to resolve conflict
      (h)elp     - show this list

    Select: (p)ostpone, (d)iff, (e)dit, (h)elp : t
    G    contrib/client-side/svnmerge/svnmerge.py
    Updated to revision 25685.

This feature can be selectively disabled by using the --non-interactive option, or disabled permanently by setting '[miscellany] interactive-conflicts = no' in your run-time config file.

The API for interactive conflict resolution is exposed via a callback function and the following new data types:

  • svn_wc_conflict_resolver_func_t, the callback API itself
  • svn_wc_conflict_description_t, a description of the conflict passed to the callback
  • svn_wc_conflict_action_t, the part of the conflict description indicating what the merge was trying to do
  • svn_wc_conflict_reason_t, the part of the conflict description indicating the type of conflict
  • svn_wc_conflict_result_t, returned by the callback as the result of any conflict resolution attempt

Clients provide their callback function to Subversion's libraries by setting it on the (new) conflict_func field of their svn_client_ctx_t, and may provide additional state to the callback via the corresponding conflict_baton field.

WebDAV transparent write-through proxy (server)

XXX: A mod_dav_svn feature activated using the SVNMasterURI directive in httpd.conf.

Cyrus SASL support for ra_svn and svnserve (client and server)

XXX: Described here.

Changelist support (client)

XXX: Described here.

Relative peg URLs in svn:externals

Two additions to the svn:externals feature

  • The URLs may include peg specifications. Because the directory a URL refers to with and without a peg revision uses a different lookup and result in different contents, the current format from older versions of Subversion continues to not understand peg revisions. A new format is introduced to allow peg revisions in URLs.

    So the old format of

              foo             http://example.com/repos/zig
              foo/bar -r 1234 http://example.com/repos/zag
            
    does not support peg revisions. In fact, these following externals will not work unless there are directories named zig@HEAD and zag@HEAD:
              foo             http://example.com/repos/zig@HEAD
              foo/bar -r 1234 http://example.com/repos/zag@HEAD
            

    The new format moves the URL first followed by the directory the external is checked out or exported into

              http://example.com/repos/zig foo1
              -r 1234 http://example.com/repos/zag foo/bar1
              http://example.com/repos/zig@HEAD foo2
              -r 1234 http://example.com/repos/zag@HEAD foo/bar2
            
    peg specifications are allowed but not necessary.

  • Up to Subversion 1.4, the URLs in an svn:externals specification must be absolute. Now they can be relative. Four different relative externals are supported.

    For the following example, assume we have two repositories at http://example.com/svn/repos-1 and http://example.com/svn/repos-2. We have a checkout of http://example.com/svn/repos-1/project1/trunk and the svn:external property is set on trunk.

    • ../
      Relative to the directory with the svn:external property. These URLs always begin with the string ../.
                    ../../project2/trunk common/project2/trunk
                  
      This will extract http://example.com/svn/repos-1/project2/trunk into common/project2/trunk. The URL is relative to the directory with the svn:external, not the directory where the external is written to disk.
    • ^/
      Relative to the repository root.
                    ^/project2/trunk common/project2/trunk
                  
      This will extract http://example.com/svn/repos-1/project2/trunk into common/project2/trunk.
      You can also refer to other repositories easily using repository root relative URLs:
                    ^/../repos-2/foo/trunk common/foo/trunk
                  
      This will extract http://example.com/svn/repos-2/foo/trunk into common/foo/trunk
    • //
      Relative to the scheme. This copies the scheme of the checkout or export URL into the URL in the svn:external. It is useful when the same hostname must the accessed with different scheme's depending upon network location; i.e. clients in the intranet use http:// while external clients use svn+ssh://.
                    //example.com/svn/repos-1/project2/trunk common/project2/trunk
                  
      This will extract http://example.com/svn/repos-1/project2/trunk into common/project2/trunk. If the working copy was checked out from svn+ssh://example.com/svn/repos-1/project1/trunk then this URL would be http://example.com/svn/repos-1/project1/trunk.
    • /
      Server root relative URLs. This copies the scheme and hostname from the checkout or export URL into the svn:external URL.
                    /svn/repos-1/project2/trunk common/project2/trunk
                  
      This will extract http://example.com/svn/repos-1/project2/trunk into common/project2/trunk. If the working copy was checked out from svn+ssh://example.com/svn/repos-1/project1/trunk then this URL would be http://example.com/svn/repos-1/project1/trunk.

    Relative URLs are supported in the old svn:externals format that do not support peg revisions.

    When Subversion sees an svn:externals without an absolute URL it takes the first argument as a relative URL and the second as the target directory.

FSFS sharding

XXX: Useful for file systems which don't perform well with a large number of files in a directory -- see blog entry here.

Enhancements and Bugfixes

Copy/move-related improvements (client and server)

The abilities and behavior of copy and move operations has improved significantly.

Improved copy-handling during updates (client and server)

A common problem in older versions of Subversion was the way in which svn update handled incoming copies and moves.

For example, suppose Harry runs svn move foo bar; svn commit, and meanwhile Sally makes local changes to 'foo', and then runs svn update. In earlier versions of Subversion, the server would send down a completely new file 'bar', and remove the file 'foo' (or rather, make it unversioned, since it has uncommitted changes.) From Sally's point of view, her changes seem to be lost; the newly added 'bar' file has the older content. In Subversion 1.5, the client and server both attempt to be smarter about this. The server doesn't send a whole new file during the update, but rather instructions to copy something that may likely already exists in the working copy. So Sally's 'foo' file is copied to 'bar' (with local edits intact!).

In theory, this is the best-case scenario. There are a few caveats: this "proper copying" of existing working-copy resources only works on files, not (yet) on directories. Also, if an incoming move-operation deletes 'foo' before it attempts to copy it to 'bar', then the copy will fail, and the client reverts to the old behavior of fetching a pristine copy of the file from the repository. We hope to address this in svn 1.6. For details on the this issue see issue #503.

Peg revisions (client)

Copy operations now accept sources with peg revisions.

Multiple working copy copy/move operations (client)

Clients may now perform multiple local copy/move operations on a single object in a working copy:

svn mv path1 path2
svn mv path2 path3

Improved handling multiple copy/move sources (client)

Clients now accept multiple sources for copy and move operations, with the ability to copy/move each of the sources to the specified directory. This mirrors the behavior of standard command-line copy and move tools, such as cp and mv. In practice, this means users can take advantage of shell globbing when doing a local copy or move:

svn cp *.c dir

Multiple source copy/move also works for all previously defined copy/move working copy and repository combinations. This was issue #747.

Cancellation improvements (client)

Clients operations are now significantly more responsive to cancellation (e.g. via control-c). In pre-1.5 releases, after directing an operation to stop, one sometimes had to wait for some time (e.g. while I/O occurred) before the operation would actually stop.

Command-line client improvements (client)

  • A --use-merge-history option to adhere to Merge Tracking meta data has been added to the following sub-commands:
    • log
    • merge
  • A --parents option to create intermediate directories has been added to the following sub-commands:
    • add
    • copy
    • move
    • mkdir
  • A --keep-local option to retain paths locally has been added to the delete sub-command.

XXX: More...

API changes, improvements and language bindings (client and server)

If you develop a 3rd-party client application that uses Subversion APIs, you may want to take notice of the following changes and new APIs:

  • svn_opt_parse_path() changes
    • Since Subversion 1.3, if a path or URL ends in an empty revision suffix '@', then the returned revision type would be different than an unprotected path or URL:
      • some/path/to/foo returns svn_opt_revision_unspecified
      • some/path/to/foo@ returns svn_opt_revision_base
      • http://example.com/some/path/to/foo returns svn_opt_revision_unspecified
      • http://example.com/some/path/to/foo@ returns svn_opt_revision_head
      Subversion 1.5 fixes this inconsistency, all the above paths and URLs return svn_opt_revision_unspecified.
    • Since Subversion 1.2, svn_opt_parse_path would always canonicalize the returned path or URL with svn_path_canonicalize, even though this is not documented in subversion/include/svn_opt.h. For the relative externals support, uncanonicalized paths need to be returned, otherwise scheme relative URLs, i.e. //example.com/some/path would be canonicalized to server root relative URLs /example.com/some/path. Users of this function now must ensure that they canonicalize the result of this function if they pass it to any other Subversion functions that expect a canonicalized path or URL.
  • XXX: Enumerate specific new API additions (e.g. merge info retrieval?)
  • APIs backing the new Command-line client improvements section have been added.
  • Many APIs have been revised to newer versions.
  • Language bindings expanded and improved

Easier to try out experimental ra_serf DAV access module (client)

Subversion 1.4 introduced the experimental ra_serf repository access module for accessing HTTP[S] DAV Subversion servers. This uses the serf library instead of the Neon library which the original DAV support uses. serf supports pipelined requests which may lead to better performance. However, Subversion 1.4 required you to choose which module to use for accessing DAV servers at build time, which made it difficult to find out which module performs better for your usage patterns.

Subversion 1.5 allows you to build both modules at the same time; you can choose which library to use on a global or host-by-host basis by setting the http-library variable in your run-time server configuration file (~/.subversion/servers). In recognition of the fact that both libraries are DAV clients, we have renamed ra_dav to ra_neon.

Other bug fixes (client and server)

The usual slew of heretofore-unreleased bug fixes, more than 40 overall. See the CHANGES file for full details.

Subversion 1.3.x series no longer supported

The Subversion 1.3.x line is no longer supported. This doesn't mean that your 1.3 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.3.x versions, and will not make any more 1.3.x bugfix releases, except perhaps for absolutely critical security or data-loss bugs.