These new features will ultimately be documented in a 1.2 version of the free Subversion book; check the svnbook.red-bean.com site.
Subversion 1.2 can best be summarized as: (1) a new locking feature, (2) full WebDAV autoversioning, (3) faster binary decompression, and (4) a large number of improved APIs. Details are given below.
Subversion 1.2 is a superset of all previous Subversion releases. The 1.0.x and 1.1.x releases contain nothing but important bugfixes backported from the 1.2 development line. Subversion 1.2, however, introduces new features and fixes many additional bugs.
Note that the 1.0.x line is no longer supported. This doesn't mean that your 1.0 installation is doomed; if it works well and is all you need, that's fine. By "no longer supported", we simply mean that bug reports are no longer accepted on 1.0.x versions, nor will there be any more 1.0.x bugfix releases (except perhaps for a critical security or data-loss bug.)
To upgrade to the latest release, there's nothing special one has to do. Just install the newest libraries and binaries "on top of" an older release. Older clients or servers will continue to interoperate with 1.2 clients and servers.
Subversion's compatibility and version-numbering policy is documented in the project's HACKING file. Here's a quick summary:
Database schema: if upgrading to Subversion 1.2, there is no need to dump and load your repository. There will be no changes requiring dump/load before Subversion 2.0.
Client/server compatibility: a 1.X client and 1.Y server are always interoperable. However, the latest features or bugfixes may not be available unless both client and server are the latest version.
API/ABI compatibility: the 1.2 release only adds new functions; thus a 1.0 or 1.1 program can both compile against and use 1.2 libraries at run-time, but a 1.2 program cannot use 1.0 or 1.1 libraries.
Although the Subversion developers try hard to keep parseable output from the command line programs compatible between releases, new information sometimes has to be added. This might break scripts relying on the exact formatting of the output. In 1.2, the following changes have been made to the client output:
For svn update, the paths have been shifted two columns to the right, thus they start in column five. Column three contains a B when a lock was broken or stolen.
svn status adds information about locks in the sixth column. Note that this column was previously unused, so the old information is still in the same positions as before.
Several lines were added to the svn info output, containing lock information.
"Locking" is a long-requested feature, often known in other systems as "reserved checkouts". While Subversion is still primarily a copy-modify-merge system focused on parallel development, there is widespread acknowledgement that not all files are contextually mergeable — binary files in particular, such as artwork, compressed files, proprietary binary formats, or any other non-line-based data.
The goal of the new locking feature is twofold. First, provide a means to force serialized write-access to a file. Second, provide a communication mechanism to prevent users from wasting time on unmergable changes.
The first goal is accomplished by two new commands: svn lock and svn unlock. When a user locks a file, no other user may commit a change to the file or delete it from the repository. The lock exists as a piece of metadata both managed and enforced by the repository. The working copy caches a lock-token which represents the repository lock. The lock-token is an authorization credential which (along with normal user authentication) gives the user an exclusive right to commit changes to the file. By default, the svn commit command releases any locks it discovers in the working copy, although this behavior can be customized.
Locks are discoverable and examinable. svn status shows any lock-tokens cached in the working copy, and svn status -u shows information about other locks in the repository. The svn info command now works on both working-copy paths and URLs, and shows the detailed fields of a lock: who made the lock, when it was made, and any associated comment. On the server, scripts can examine a lock directly via svnlook lock.
Locks can be stolen or broken by using the --force option with svn lock or svn unlock. Using the new pre-lock and pre-unlock repository hooks, administrators are free to enforce custom policies regarding breaking and stealing locks. (In fact, the entire locking feature can be completely disabled by making pre-lock always return failure.) There are also new post-lock and post-unlock hooks which can be used to send announcement emails about locks. Administrators can forcibly find and destroy locks with the new svnadmin lslocks and svnadmin rmlocks commands. If a lock no longer exists in the repository, svn update will remove a corresponding "defunct" lock-token from the working copy.
The second goal — preventing a user from wasting time on an unmergable change — is accomplished via a new property, svn:needs-lock. Users (or administrators) are encouraged to set this property on any file that is unmergeable. When present, this property causes the file to be read-only unless the working copy holds a lock-token for the file, in which case the file is read-write. The theory is that the default read-only state will remind users to lock the file before attempting edits. Note that while this system is effective, it can never be perfect; there's nothing Subversion can do to prevent a rogue application from forcibly "hijacking" the file and changing the permissions to read-write.
Until the Subversion book documents this feature more carefully, you can see more details in the original functional specification and UI specification documents.
Warning: if locks are in use in a repository, then a pre-1.2 libsvn_fs library won't see or enforce them. This is really only relevant to teams of users all accessing the repository via file://. For example, an svn 1.2 client might lock a file, but a statically-linked svn 1.1 or 1.0 client (accessing via file://) will unknowingly ignore the lock. The workaround, of course, is to set up a real server process — thereby guaranteeing that only libsvn_fs 1.2 ever accesses the repository.
Autoversioning is a feature whereby generic WebDAV clients can write to a DeltaV server (like mod_dav_svn), and the server performs commits silently in the background. This means that if you use Apache httpd as your Subversion server, then most modern operating systems can mount the repository as a network share, and non-technical users get "transparent" versioning for free. (Of course, technical users can still use Subversion clients to examine repository history.)
Prior to Subversion 1.2, mod_dav_svn had only partial interoperability with generic DAV clients. Appendix C in the Subversion 1.1 book documented the trials and tribulations of this exercise. At most, one could use a DAV client to drag files into a mounted repository, but the files couldn't be edited directly from the network share. Some clients even refused to mount the Subversion repository.
Now that the repository supports locking, generic DAV clients can happily issue http LOCK and UNLOCK requests, and files can be opened/edited directly from the share. As far as we can tell, mod_dav_svn is now fully implementing the 'autoversioning' feature according to the RFC2518bis specification.
In informal tests, we've had success reading and writing to Subversion repositories via Windows Web Folders, OS X Finder, Gnome Nautilus, KDE Konqueror, and other DAV clients.
To activate autoversioning, simply set SVNAutoversioning on in your httpd.conf's Subversion Location block. Be warned, however, that making your repository writable by generic DAV clients may result in lots of small commits. A DAV client may seem to be saving a file, but is in fact performing several write operations under the hood, each resulting in a separate commit. Experiences may vary.
The repository is now using the xdelta binary-differencing algorithm (instead of vdelta) to store compressed binary difference data. When you upgrade to Subversion 1.2, existing repositories will continue to work fine; the history will simply be a mixture of differences generated by vdelta and xdelta.
The xdelta algorithm is much faster at reconstructing older files, and thus there's motivation to dump and reload your existing repository. If you choose to do this, then you're forcibly re-compressing all repository history using the xdelta algorithm. As a result, there is a noticeable speedup in any operation that asks the server to reconstruct older data: svn blame, svn checkout, svn update, svn diff, svn merge, and so on. Even dumping the repository will be faster.
Note: There's a small trade off between speed and disk space. If you choose to re-deltify your whole repository using xdelta, its size will grow by roughly 10 to 15 percent.
After the tremendous success of FSFS repositories since the 1.1 release, we've changed the svnadmin create command to create FSFS repositories by default. Everyone agrees that this will provide a much friendlier "out of box" experience for new users.
Please note: Berkeley DB repositories are not being phased out or deprecated in any way. The reliability problems we've seen lie not in Berkeley DB itself, but in the unique way Subversion uses Berkeley DB. Cooperative work is currently underway (with Sleepycat engineers) to address these issues. Berkeley DB repositories are still older and better-tested than FSFS repositories in terms of scalability; the project still recommends you read about the two back-ends in the book and make an informed choice.
On Windows 2000 and later, the command-line client encrypts the cached passwords used for authenticating to a remote Subversion server (via the http:// or svn:// protocols). Existing, unencrypted cached passwords are automatically encrypted the first time they are used.
Note: The client uses the standard Windows Cryptography services to encrypt and decrypt the password. Among other things, this means that the encryption key is managed by Windows and can only be accessed by the user account that owns it. If an administrator forcibly resets the account password, the encryption key (and consequently the cached passwords) will no longer be accessible (by the way, the same holds for the contents of NTFS-encrypted files). The Subversion client will detect this and proceed as if the password were not known; that is, it will prompt the user for the password when necessary.
Note: This feature does not extend to stored passphrases for client SSL certificates.
More than 50 new bugs fixed. See the CHANGES file for details.
The svn_ra.h API has now been "flattened", essentially imitating the same way the svn_fs.h API hides multiple implementations. Instead of making calls into an RA vtable (ra->do_foo()), all RA functions are now usable directly in the form svn_ra_do_foo(). This also has the nice side-effect of making svn_ra.h available via SWIG.
As with svn 1.1, a number of new 1.2 functions have been introduced, and older versions are now marked deprecated (and will be removed in Subversion 2.0). See the CHANGES file for details. The full list of new 1.2 APIs is here.
There has been extensive work on the Python, Perl, and JavaHL bindings. We also now have a preliminary set of Ruby bindings.
See our roadmap for what the future looks like.
If you're looking for testimonials on Subversion, see our new testimonials page.
As usual, you can find links to other Subversion-related sites, projects, and essays on our links page.