Subversion 1.3 Release Notes

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.3, the following changes have been made to the output:

• 'svnlook diff' always diffs added files by default now, and the new '--diff-copy-from' option causes those diffs to be against the copyfrom source instead of against an empty file (for consistency with 'svn diff'). Also, when diffing against the empty file, the diff headers now say "revision 0" instead of the copyfrom revision (again for consistency with 'svn diff').

• 'svn diff' output is now in native encoding, instead of in UTF8.

• Merge conflict markers are now in the encoding of the user's locale. (Not exactly a command line output change, but near enough).

• 'svn ls --verbose' now shows remote locks as 'O', just like 'svn status -u' does.

Unexpected Berkeley DB Upgrades ¶

This is not actually related to the Subversion 1.3 release, but it may affect you if you upgrade to 1.3 via a package distribution system.

A lot of operating systems now ship Berkeley DB 4.3. Sometimes the system Berkeley DB libraries can be unintentionally upgraded to 4.3 as part of some other change pulled down via an OS package delivery mechanism — for example, upgrading one's Subversion package. If this happens to you, you will need to upgrade existing BerkeleyDB-based repositories to 4.3.

Since Subversion 1.2, the Windows binary distributions of Subversion from Branko Čibej use Berkeley DB 4.3. If you are upgrading from an older version, the above may be of concern to you.

Path-based authorization for svnserve (requires new server) ¶

svnserve, the stand-alone Subversion server, is now able to restrict both read and write access using the same authorization-policy files used by mod_authz_svn. (Previously, the most one could do with svnserve was restrict write-access via pre-commit hook scripts.)

The authorization file format is the same one described here, in Chapter 6 of the Subversion book. You simply need to point to it from your repository's svnserve.conf file using the new authz-db directive:

[general]
password-db = userfile
realm = my realm

anon-access = none
auth-access = write

authz-db = authzfile

Note that when the authz-db directive is in use, the "blanket" access directives (anon-access and auth-access) can still be in effect too. In order to access a path, both the "blanket" directives and per-path authz file must allow access.

Operational logging for mod_dav_svn (requires new server) ¶

The Apache HTTPD-based server (mod_dav_svn) is now able to log high-level Subversion operations, e.g., "update", "lock", "commit", etc. This is an improvement over trying to read and understand the mysterious chains of WebDAV methods currently listed in httpd's accesslog file.

To activate this new feature, you need to make use of httpd 2.0's built in logging directives such as LogFormat and CustomLog directives. These directives allow you to flexibly define your own log formats. All you need to know is that mod_dav_svn now sets an environment variable named SVN-ACTION whenever it feels that an http request has completed a particular subversion-related action. So, for example, the following httpd.conf directive would log all subversion-related actions to a private logfile, along with timestamp and username:

CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION

Equivalent functionality is planned for svnserve, the standalone server, but not until Subversion 1.4, because the implementation strategy there will be a bit different. See Issue #2409 for details.

Major Language Binding Improvements ¶

• It's now possible to build the SWIG bindings from source without installing SWIG, because we now bundle the generated output of SWIG with the release tarball.
• The Python and Ruby bindings now support automatic memory management. If you don't supply Subversion API functions with memory pools, Subversion will automatically manage its own memory.
• The Python and Ruby bindings are now more stable, as verified by our expanded test suites.
• The Ruby bindings now offer complete coverage of the Subversion APIs.

New subcommand switches ¶

svn blame --xml [--incremental]

svn status --xml [--incremental]

svn info --xml [--incremental]

Display output in XML. If --incremental is also used, then output XML suitable for concatenation.

svn add --no-ignore

svn import --no-ignore

Disregard all "ignored" file patterns.

svnlook tree --full-paths

Show full paths instead of indented ones.

svnlook diff --diff-copy-from

Print differences against copy source.

svnlook changed --copy-info

Show details for copies.

Listing available repositories in mod_dav_svn (server) ¶

The Apache HTTPD-based server can now display (in a web browser) the collection of repositories exported by the SVNParentPath directive: simply set 'SVNListParentPath on' in httpd.conf.

Interruptible http(s):// connections (client) ¶

If built with Neon 0.25.1 or higher, Subversion can be interrupted during network operations over http:// and https://. This is a long-standing bug that has finally been fixed.

Official support for Windows '_svn' directories (client and language bindings) ¶

The "_svn" hack is now officially supported: since some versions of ASP.NET don't allow directories beginning with dot (e.g., ".svn", the standard Subversion working copy administrative directory), the svn command line client and svnversion now treat the environment variable SVN_ASP_DOT_NET_HACK specially on Windows. If this variable is set (to any value), they will use "_svn" instead of ".svn". We recommend that all Subversion clients running on Windows take advantage of this behaviour. Note that once the environment variable is set, working copies with standard ".svn" directories will stop working, and will need to be re-checked-out to get "_svn" instead.

Third party software that uses the Subversion libraries needs to be updated to make the equivalent API calls. See the three new APIs: svn_wc_is_adm_dir, svn_wc_get_adm_dir, and svn_wc_set_adm_dir. Setting the SVN_ASP_DOT_NET_HACK environment variable only works for the above-mentioned client programs, and only on Windows. It doesn't work for libraries; users of the libraries should call the new APIs, which are platform-independent. See this mail and its thread for more details.

Performance improvements (client and server) ¶

svn status is a bit faster, as is any command that involves tracing long lines of history, such as svn log. See issue #1970 for details.

It's particularly noticeable when svn blame is run on a file with a large amount of history, or when invoking any command on an older "peg" revision.

API improvements (client and server) ¶

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

• The APIs used by 'status --show-updates' now make URI, youngest revision, date last modified, youngest node kind, and most recent author available as reported by the server, in addition to the status reflected by the working copy.
• There's now a data-transfer progress callback for ra_dav.
• The repository root URL is now being stored as a separate field in .svn/entries.
• Many APIs have been revised to newer versions.

Other bugfixes (client and server) ¶

The usual slew of heretofore-unreleased bugfixes. See the CHANGES file for full details.

Changes in the working copy format ¶

Subversion 1.3 features a minor change in the way properties are stored in the working copy, which reduces the size of some working copies significantly. From the user's point of view, the change is completely transparent. That is, your working copies will go on working, even with older clients.

However, programs that interact with the working copy property files without using the official Subversion APIs or binaries may experience problems. JavaSVN (now known as SVNKit) is the only project that we know of that falls into this category, and they have been notified accordingly. If you happen to be using or developing software that, similarly, bypasses the Subversion APIs, then you may need to make a minor alteration to the parsing routines. See revision 16855 of the Subversion repository for details.