Details are described below.
Subversion 1.3 is a superset of all previous Subversion releases. Anything in 1.0.x, 1.1.x, or 1.2.x is also in 1.3, but 1.3 contains features and bugfixes not present in any earlier release. The new features will eventually be documented in a 1.3 version of the free Subversion book, see svnbook.red-bean.com.
Subversion 1.3 is available as source code in three formats:
For binary packages, please see the binary package list. Note that binary packages usually come out about a week after the corresponding source release. The package maintainers are volunteers, so please don't harass them — they know when a new source release has come out, and they work as fast as they can to make binaries available.
For other Subversion releases, see this folder.
Older clients and servers interoperate transparently with 1.3 servers and clients. Of course, some of the new 1.3 features may not be available unless both client and server are the latest version. There is no need to upgrade your repositories; Subversion 1.3 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. (WARNING: if you're using Berkeley DB repositories, installing a new binary distribution of Subversion may force you to upgrade Berkeley DB as well, see Unexpected Berkeley DB Upgrades below.)
Subversion 1.3 maintains API/ABI compatibility with earlier releases, by only adding new functions. A program written to the 1.0, 1.1, or 1.2 API can both compile and run using 1.3 libraries. However, a program written for 1.3 cannot necessarily compile or run against older libraries.
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.
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.
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.
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.
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.
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.
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.
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.
If you develop a 3rd-party client application that uses Subversion APIs, you may want to take notice of some new APIs:
The usual slew of heretofore-unreleased bugfixes. See the CHANGES file for full details.
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 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.
The Subversion 1.1.x line is no longer supported. This doesn't mean that your 1.1 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.1.x versions, and will not make any more 1.1.x bugfix releases, except perhaps for absolutely critical security or data-loss bugs.