Merge Tracking Improvements
Every major release of Subversion (and many minor ones) since version 1.5.0 delivered incremental improvements to Subversion's merge tracking feature, and this release is no exception. Since the 1.6.0 release, Subversion's developers have identified and fixed nearly 80 bugs and enhancements related to Subversion's ability to efficiently and correctly track and manage merges of changes between branches. Many of those fixes have already been released to the public via the subsequent 1.6.x releases, but Subversion 1.7.0 alone provides more than 40 of these improvements.
One of the key improvements is the handling of merge tracking metadata on working copy paths under a merge target (known as "subtree mergeinfo"). No longer does a merge unconditionally update all subtree mergeinfo to describe a merge. In 1.7 only the subtrees affected by the merge are updated. This addresses a common complaint about the amount of "noise" in the form of mergeinfo changes produced by relatively simple merges.
With Subversion's widespread (and growing) adoption in enterprise environments many of which employ heavily branch-centric development processes every improvement to this feature is a welcome one.
Improved Difference Marshaling
Experienced Subversion users are familiar with Subversion's built-in "diff" functionality, which displays line-based changes between two files or two versions of the same file. This information is, of course, useful to the humans reading it ("What changes did I make to this file's contents?"), but is also presented in the standardized unidiff format, which can be stored in a patch file, shared with another user, and then parsed by a "patch" program in order to apply those same changes to a different copy of the file. Unfortunately, "patch" is concerned only with content changes to text files. It knows nothing of the other types of changes that can be represented in Subversion working copies: changes to file and directory versioned properties; changes to the directory hierarchy caused by adding, removing, and copying items around; changes to the contents of non-human-readable files; and so on.
Subversion 1.7 offers some improvements to its "diff" functionality, enhancing the output format to represent changes to versioned properties in a more reliably machine-parseable way and offering an output mode that is compatible with the popular git version control system. But those improvements alone don't necessarily help other Subversion users apply someone else's patch files to their own working copies. So Subversion 1.7 also introduces built-in support for parsing its own "diff" output and applying the changes found there to a target working copy. Today the new "svn patch" command can parse and apply content modifications made to human-readable files, modifications to Subversion file properties, and simple file additions and deletions. Future releases of Subversion are expected to deliver the completion of this feature, ultimately allowing the ability to reproduce every type of local change that Subversion allows in its working copies.
... And Then Some
It goes without saying, but good developers can fix a tremendous number of bugs in two years' time. The CHANGES file provided with the source code distribution of Subversion 1.7 lists over 150 improvements to the software, and those are just the ones deemed worthy of mention. And while this article covers the most high-profile features of the release, that coverage is far from exhaustive. Subversion 1.7 offers many more improvements, perhaps one of which is precisely the one you've been waiting for. For more information, consult the project's official release notes online.