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.
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.
Due to certain improvements and bugfixes made to the FS library, the version number of the repository format has been incremented. This means that pre-1.5 Subversion tools that normally access a repository directly (e.g. svnserve, mod_dav_svn, svnadmin) will not be able to read a repository originally created by Subversion 1.5.
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.
XXX: Describe each new feature. See the 1.4 RNs for a "template".
XXX
XXX: Described here.
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
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
itselfsvn_wc_conflict_description_t
, a description of the
conflict passed to the callbacksvn_wc_conflict_action_t
, the part of the conflict
description indicating what the merge was trying to dosvn_wc_conflict_reason_t
, the part of the conflict
description indicating the type of conflictsvn_wc_conflict_result_t
, returned by the callback
as the result of any conflict resolution attemptClients 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.
XXX: A mod_dav_svn feature activated using the SVNMasterURI directive in httpd.conf.
XXX: Described here.
XXX: Described here.
XXX: Useful for file systems which don't perform well with a large number of files in a directory -- see blog entry here.
XXX
XXX
--use-merge-history
option to adhere to Merge
Tracking meta data has been added to the following sub-commands:
--parents
option to create intermediate
directories has been added to the following sub-commands:
--keep-local
option to retain paths locally has
been added to the delete
sub-command.XXX: Should this go into the APIs section?
If you develop a 3rd-party client application that uses Subversion APIs, you may want to take notice of some new APIs:
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.
The usual slew of heretofore-unreleased bug fixes, more than 40 overall. See the CHANGES file for full details.
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.